This documents the buildinx command for making a bootable INX Live CD iso image.
buildinx must be invoked as root, or using the sudo command. You do not need to create the build directory - buildinx will do that on its first run. Just be sure to run buildinx from the same spot each time :)
The command is shown here in the form ./buildinx , since copying the script to the desired directory makes this more certain - but you can of course invoke it as simply buildinx , if it is placed in your PATH.
[sudo] buildinx name repository
The buildinx script takes two arguments: a "custom" name (example: myversion) and an Ubuntu repository name (example: archive.ubuntu.com)
It uses wget, debootstrap and apt-get with help from dpkg and aptitude to create a build directory, a "chroot" , a "master", install needed applications and extras, then make a squashfs file system, isolinux boot mechanism and finally a bootable CD iso image.
It is invoked from the directory above the build directory. If the build directory does not yet exist, it creates it with the name
BuildInxWorkingDirectory
On first run, this directory is created by the script. Thus subsequent invocations of buildinx should be run from the directory above "BuildInxWorkingDirectory" (see examples below)
The build directory can contain a number of different builds - for example say beta1-inx , beta2-inx , RC1-inx . Subsequent "runs" to re-modify a particular build use its name - e.g. RC2 , beta , myspecialversion or whatever the previously chosen name happens to be.
buildinx does these steps with some interaction from the user, and allows changes to be made in the chroot.
repository Typically of the form "countrycode.archive.ubuntu.com" , but is modifiable in the script variable names for special cases where mirrors for example use subdirectories.
sudo ./buildinx extrasalami au.archive.ubuntu.com
sudo ./buildinx darkteatime gb.archive.ubuntu.com
cp buildinx inx/
cd inx
chmod +x buildinx
The above steps are only needed before running the script for the first time, of course. The actual run is started (in this case, where we have named the build "better-version", and chosen to use archive.ubuntu.com) :
sudo ./buildinx better-version archive.ubuntu.com
This first run creates inx/BuildInxWorkingDirectory, and places the chroot and master directories in it. The final iso also lands in inx/BuildInxWorkingDirectory/name-inx/ , so after the first run you would see
ls inx/BuildInxWorkingDirectory/
better-version-inx
ls inx/BuildInxWorkingDirectory/better-version-inx/
chroot master inx-better-version.iso
ls inx/BuildInxWorkingDirectory/better-version-inx/
080812-19:25.inx-better-version.iso chroot master inx-better-version.iso
After the first run you would also see in BuildInxWorkingDirectory :
ls BuildInxWorkingDirectory
better-version-inx inx-extras
The "inx-extras" is a directory created from the tarball of extras that the first run of the script downloads using wget, normally from the inx.maincontent.net server.
If you are running buildinx in X, the script will also look for a CD burning program (either the Nautilus CD burner or K3b) and offer to open the iso in the program for burning to CD.
You can decline this offer if you wish ;-) Often you will prefer first to test the iso by running from it in a virtual machine like qemu or virtualbox, for example.
Under certain circumstances you might wish to re-do a step that these files "lock" after the first run. Reading the script should show you what each of the files does. This is left as an exercise for the reader ;-)
The script pretty much does everything for you, and explains itself, prompting where needed. You probably want to make your first run a simple clone of INX, which means selecting the default when you see a menu. ( "1: Let the script complete a clone of INX for you." )
It is best to run the script in a fairly large terminal - maximise your chosen terminal app if you are running buildinx in X.
Main hint: The worst that can happen is that the script fails for some reason. This won't do anything to your system. Do not interrupt the script, as an interruption in the wrong place can cause problems with the dpkg tools etc. and will require "dpkg --configure -a" at least.
Be aware that the script runs as root - therefore, if you use your home directory for the build directories, their files will be owned by root. You might prefer for example to create a directory in /var for your builds.
Peter Garrett <inx-one does not like spam at optusnet.com.au>