Aboriginal Linux 1.2.0.x

This file is taken out of the 'aboriginal-project-' tarball

This project is a resuscitation of an old version of the famous Aboriginal Linux created by Rob Landley.


Rob developed Aboriginal up to version 1.4.5, early-2016, then retired from the project. See the history and retirement announcement:


Back in the "early days", Rob used uClibc and Busybox as the core of Aboriginal. Later, he gradually replaced Busybox applets with his own creation, Toybox. Then, mid-2015, he moved from uClibc to Musl.

I prefer uClibc over Musl, mostly due to the former's better compatibility with glibc. I also have no motivation to replace Busybox with Toybox. Hence, I have stayed with version 1.2.0, that was released in 2012.

Why use it?

As a Linux developer, I have a need to compile some utilities statically. That is, they do not use any shared libraries.

I use these utilities in the initrd/initramfs, but also in the main Linux filesystem. The single greatest advantage of a static utility is that it is completely self-contained and will work in any Linux, into the future -- there will never be any library compatibility issues.

The downside is that static utilities are big, as, essentially, they have the library functions bullt-in to them. This is where uClibc and Musl come in, as their libraries are "lean and mean" and will produce much smaller binaries than if the utilities are compiled against glibc (Gnu libc, which is what all the Linux distributions use).

To give an idea of the size difference, 'dmsetup' (a utility in the LVM2 package) is 128KB (stripped) when linked against shared libraries, 517KB (stripped) when linked statically against uClibc. A smaller utility, 'hwclock', is 36KB versus 92KB.

Another utility that is interesting to compare is Busybox. Configured fairly full-featured, as I use in Quirky and EasyOS, linked against shared glibc, the 'busybox' binary is 850KB. Compiled in Aboriginal linux and linked statically against uClibc, it is 966KB.  The static utility is not much bigger!

Another place where you might use static utilities, is during early bootup of Linux, in the main filesystem. Even if the system has been "stuffed up", with maybe incompatible libraries installed, if 'init' and the basic bootup utilities are static, then they will still work and get you to a commandline.

Oh, one more thing -- a 32-bit static utility will work in a 64-bit system. No need for 32-bit libraries.

Version 1.2.0

I have been using version 1.2.0 for years. as a chrootable filesystem. That is, I can chroot into it, from whatever host distro I am running (usually Quirky or EasyOS), and then can compile source packages that will be linked against uClibc.

Recently though, I hit a problem, was unable to compile package 'LVM2', as it requires the 'fmemopen()' function, that is not in uClibc.

Or rather, it is, but not enabled. I was using a precompiled x86_64 root-filesystem, downloaded from Rob Landley's site.

Rob uses uClibc version, which is the last official release of the uClibc project. That was in 2012. I discovered that there are additional glibc-compatibility options, including fmemopen(), so, I needed to recompile uClibc...

I downloaded 'aboriginal-1.2.0.tar.bz2', which is the source code, which can be used to compile architecture-specific root-filesystems, for example x86_64 or armv6l. For the record, this is where to get it:


I modified the configure option for uClibc, and also bumped the kernel version from 3.5 to 4.3 (got that out of aboriginal 1.4.5), then compiled for a x86_64 target. Then had a new x86_64 chrootable root-filesystem.

And, LVM2 compiled!

Version 1.2.0.x

I thought that others might find this useful, so have forked it as a new project. Version numbering will be "1.2.0.x", where the "x" is my enhancements. At the time of writing, it is "".

The project is setup as three folders, "binary", "source" and "work". In the latter folder, you will find a HTML file that explains how to use aboriginal-1.2.0.x.

Myself, and anyone else who is interested, can continue to pump steroids into this old "1.2.0". Reconfiguring uClibc and bumping the kernel, were just the first step.

The original official uClibc project was active on the project's git-repository until mid-2015, when work stopped, and a new project, 'uClibc-ng' took over.

I checked-out the latest from the official uClibc git-repo, last commit was 2015-07-05. Put it in aboriginal, but compile failed, with a missing symbol "__builtin_unreachable". This was introduced with gcc 4.5, however, aboriginal 1.2.0 uses gcc 4.2.1. I think that you might guess where this is heading...

I bumped gcc to version 4.5.4, and modified some of the previous patches, but compile failed.

Rather than chase that one, I backed off, kept the uClibc and gcc 4.2.1. After all, there is no pressing need to upgrade, as all the source packages that I want to compile, busybox, etc., do compile.

Anyway, there could be lots of fun for someone, to play with updating the packages.

In 'rootfs-', the x86_64 root-filesystem compiled by aboriginal, I have put in build scripts for 'ncurses', 'bash', 'busybox', 'coreutils', 'patch' and 'LVM2'.
A project would be to move those into the 'aboriginal-1.2.0.x' source tarball.

Another useful project would be to add a "aarch64" target. Even "armv7l", as currently there is only "armv6l".

Lots of fun! Do read the help-file in the "work" folder.


The original official uClibc site:

uClibc-ng site:

Barry Kauler
March 9, 2018
Blog: http://bkhome.org/news/