Linux on System z: Building, Unbuilding, and Rebuilding

by David Boyes, Ph.D.
December 9, 2008

Some days, you’d think that Aristotle lives somewhere east of Washington, DC, and is making a living as a political pundit. The title of this issue’s column originally referred to the making of the scholar-prince in Greek society, but it’s also an interesting observation on the evolution of Linux distributions and the way we seem to be able to propagate special purpose items, or find some “generic” things in the oddest places.

Building a Linux distribution is a lot harder than it looks, and the value of buying a distribution from a commercial distributor is getting someone else to do the dirty work— that much is clear. The testing and verification components go without saying, but the key question is what should go into a distribution that’s oriented toward the enterprise server market, especially on a platform that isn’t based on the generic Intel PC platform served by the mainline Linux distributions. I’ve recently been surprised by problems with installers and package dependencies that load support for such things as PC sound cards and USB management utilities on System z equipment. Last time I checked, my System z surely didn’t have a sound card—why do I need drivers for it, especially if all they’re going to do is decide I don’t have a sound card and exit?

In most of the current distributions, packagers and distributors try to stay consistent across platforms—the same list of packages, even if they’re not particularly (or at all) relevant. This creates a “dependency hell.” If you practice the philosophy of minimal installation, these hard-coded dependencies in packages play merry hell with the ability to remove unnecessary code—other things depend on them, and you quickly end up with an unusable system if you start pulling the plug on these “extras.” Some second-tier distributions offer a “minimal” installation profile, which is increasingly becoming critical to the enterprise in that as more stringent auditing and reporting requirements come into play, we have to account for extraneous packages to more people, which raises the cost of operations for a Linux-based environment.

One of the more useful items to come from the user community—contributed by Mark Post of Novell in his not-so-copious spare time—is a set of customized install profiles to minimize the footprint of an installed distribution of SLES, essentially a way to “unbuild” the decisions that the SuSE master packagers made while building a new Linux system. These scripts (obtainable from http://linuxvm.org/Patches/S390/autoinst.zip for SLES 10 GA and

http://linuxvm.org/Patches/S390/autoinst.sp2.zip for SLES 10 SP2) substantially pare down the bloat, offering one man’s take on a minimal system as a user-supported option. It would be nice to see these options in the next SLES service pack from Novell, but nothing official has yet been said about this.