ok, so maybe we're at aloofix v2.0

Here's another in the Aloofix series.

hah! Big surprise! Another workbench change!

So here's the story,

I've been noodling with several different distro development tools. I like several of them, but each has at least one attribute or another that drives me nuts.

This brings us to...



Version 0.8 of my workbench.

I ditched the distro builders altogether, opting for a 'hand-rolled' distribution.

To be sure, this is most likely how the other distribution building tools were created. *sigh*

As of this evening, I now have a bootable CD, a set of installation scripts run from the CD, and a HD that boots a basic distro. It's raw, but it works.

The HD distribution currently contains the following packages:

• linux-2.6.23
• glibc-2.7
• busybox-1.8.2

I'll spare you the nigglies in the TODO list.

The CD image is 20MB. Approximately 16MB of this is a gzipped cpio payload for the HD installation. The vast majority of the payload is glibc.

Will there be a version 0.9 of the workbench? I sure hope not. With any luck, future revisions will simply be improvements in the level of automation for creating the images. Having said this...

For what it's worth, I did get a complete LAMP stack build using the previous workbench, but I wasn't in the mood to man-handle uclibc to get some of the more interesting scripting languages up and running.

Aloofix 0.1 (or whatever it's called) lives!

In Building a builder for tiny lamps, I described my progress creating an environment for experimenting with Pile of Lamps.

That article left off with plans to build a working default distro with T2, then create a new minimalist target configuration.

Well, I did manage to get a working default distro.

Woohoo!

On to creating my own target definition.

Bzzzt...

I created a new target, started the "death by build iterations", then ran into problems. I'll spare the ugly details, but suffice it to say I spent more time surfing through piles of shell build scripts than creating an actual distro.

This brings us to version 0.7 of my workbench. :-)

I'm still running VirtualBox, but am now using Buildroot, from the uClibc folks, for the toolchain. I used uClibc and BusyBox years ago, and was contemplating its use for this project anyway.

As an added bonus, the builds take considerably less time than with T2.

So where am I at now? Well, I have a booting CD image and am working through the details of turning it into an installation disk.

The CD iso image is just over 19MB, with an installation payload. I have plans to make it smaller. At around 4MB, the kernel modules in /lib/modules are a notable contributor to the size. The virtual machine environment provides a predictable list of required drivers, but I need to go through the exercise of trimming down the list in the kernel configuration.

As for problems, the only one I've run encountered thus far is the fact that Buildroot doesn't include a boot loader in the list of packages available for target environments. Hmm... It's intended for embedded environments, so I'm only mildly surprised. I managed to shoehorn in a statically compiled version of grub, so it's no big deal.

I have a preliminary root filesystem for the hard drive installation. It still needs work, but it's enough to boot from a virtual disk image in Virtualbox.

The current distro installed on a hard drive contains the following primary elements:

• Linux 2.6.23 (need to bump to latest patchlevel)
  
• uClibc 0.9.29
• Busybox 1.7.2 (not sure why it's not at 1.8.2)
  

Ok, so here's the latest plan of attack.

The first order of business is to convert my hard drive installation notes into a script that runs from the CD boot.

I've started to add some additional packages.

• openssh
  installed, but it dumps core - investigating...
• lighttd
• and a scripting language
  (sadly, the perl port is very minimal - will need to ponder)
• and a database
  (still researching - berkeleydb and sqlite recipes are included in buildroot - will need to ponder)
  

As I mentioned earlier, I want to scrub the kernel configuration to remove unnecessary drivers and whatnot.

I'm also considering trimming down some of the BusyBox applets enabled by default. This is not to reduce the size - it's more to reduce the number of moving parts. E.g. fdformat and unix2dos probably aren't necessary. It's questionable whether the filesystem creation utilities are needed as well. The original concept was to only provide enough to perform the task at hand.

With luck I'm hoping my next status update will report an alpha release CD-based installer that produces a ready-to-use minimal LAMP instance. Fun stuff...

I haven't yet decided on a name for the distribution. The tentative name is aloofix. I've love to hear recommendations for a better name.

More to come...

Until next time...

Building a builder for tiny lamps

In How much of an OS distro is necessary for a Pile of Lamps, I described my basic environment for exploring ideas related to Pile of Lamps.

I've tweaked the workbench a bit, so I'm now at version 0.6. The primary difference is the addition of a dedicated build server. My laptop, while sufficiently beefy, is somewhat prone to thermal problems. The burden of lengthy compile cycles was too much, so I cobbled up a dedicated server for compiles. As an added benefit, I can continue compiling while the laptop is suspended.

The build server is running the T2 distro. The more I use T2, the more I like it. Thus far, I've only encountered one problem. The installation of perl in 7.0-rc2 appears to be missing quite a bit of /usr/lib/perl5. A forced rebuild of perl rectified the problem.

Ok, so here's the current plan of attack.

I'm initially building the default distro defined by the generic T2 recipes. This is primarily to familiarize myself with T2 and to make sure the entire tool chain works.

I was hoping to have the generic build done this weekend, but the build server took priority. The generic build is compiling as I write this blog article.

Once I have a working generic T2 target, I'll shift my attention to the creation of a new target definition. While my end goal is to create a clean recipe for the desired distro, I might need to toy around with whittling down an existing recipe until I get a handle on the T2 build environment.

Until next time...

How much of an OS distro is necessary for a Pile of Lamps

The recent conversation on Pile of Lamps rekindled an interest from a previous life - distro engineering.

My current focus has been to select an initial set of workbench tools.

Here's my version 0.5:

• VirtualBox - I could have just as easily chosen VMWAre, but this is a home project, so economy reigns. I do want to work out the process with both products, so I've probably take a look at EasyVMX in the not too distant future. Early results confirm my original suspicions - VMWare is definitely the king of the hill, but VirtualBox does nicely for now.
  
• T2 - This is a recent discovery. It's a fork of Rock Linux. They provide a nice system development environment well suited for building distributions.
  

I can hear it now.

"But we already have gabillions of distros -don't even think about building another one!"

Hurrumph...

Like blogs, there can never be too many distros. :-)

Call it my take on Just Enough OS.

Much of what is contained in most distros is excess baggage, catering to an audience wanting all manner of doodads. Granted, there are minimalist distros, stripped down to a bare bones environment. My primary issue with these is that they tend to be focused on squeezing as much functionality into as small a space as possible. The problem space for Pile of Lamps appears to be different.

For Pile of Lamps, or JeOS, the key design goal should be to remove as much complexity as possible. The dramatic increase in the apparent number of running machines compounds the the problem of system management. Perhaps an appropriate solution is to strip the base installation to a bare minimum. Here's a quick list of the more obvious benefits.

• Less to upgrade
• Less to configure
  
• Smaller security risk footprint
• Faster to transport over the wire

In its most extreme form, the kernel's call to init could reference the end application, but there are several piddly details that make the use of init (or equiv) worth serious consideration. At any rate, these types of design trade-offs are at the heart of my little experiment.

Let me know what you think.