NOTE: This document is incomplete – I am working on getting all of the necessary files in place for the downloads to work properly.
In order to compile Coyote Linux 4.0 from scratch, you will first need a base Linux system to use for a build host. At present, a CentOS 6.2 x86_64 system is being used as the official build host. To create a system with identical properties to the official build host, you will need to download CentOS from one of the mirrors at http://www.centos.org. If you are unfamiliar with CentOS, it is simply a re-compile of the official sources released from Red Hat. As such, a Red Hat Enterprise 6 or Scientific Linux 6 system should work properly as well. At this point, I have not tested other distributions for use as the build host… although, I do use an OpenSuse 12 system as a desktop work environment (I prefer KDE to Gnome and like my desktop environment to keep up with changing/advancing technologies). CentOS is used as a build host to ensure a consistent build environment with an extended life cycle (the upstream vendor life cycle is 5 years for a given major release).
Setting up the build environment
- Download and install CentOS 6. During the installation of CentOS, the option to “Customize Now” ?áfor the software packages and the “Software Development Workstation” option needs to be chosen.
- Once the system is up and running and you have your network configured, make sure to update your system with the latest patches. This can be accomplished from the GUI system update tool or by running the command “yum update” as root from a command line.
- You will also need to run the command “yum install glibc-static glib2-static gpm-static” from a root shell prompt.
- If you get any messages about needing additional utilities during your first build, you will need to install them as well. Your mileage may vary.
- Create a directory called /devel/coyote (you can place this directory in various other locations, but for the purposes of this document, /devel/coyote is assumed)
- WARNING – I do all of my build work while logged in as root. While is this typically considered a bad Linux security practice, there are several functions performed (namely the creation of device special files and mounting of loop devices) during the build process which require elevated privileges. This is also another reason I have a dedicated build host which is separate from my desktop machine… if I hose my build host, there is very little customization done to the host outside of a default install and installation of update packages. I also use a fairly beefy physical server which is running VMWare ESXi 5 and has an 8 drive RAID array and 48GB of RAM. The build host and all of the test installs, build system, etc are all hosted on the same physical VM hypervisor… this is not required, but makes it my development cycle a little easier and less power hungry than running multiple machines. This also allows me to “clone” my build host to keep a version I can revert to if need be.
- Optional: I use a separate virtual disk that gets mounted on /devel. This keeps the OS installation and the build tree separate – this is handy to prevent filesystem fragmentation and to allow me to restore / rebuild the build host itself without having to backup/restore the build tree.
NOTE: As of the writing of this document, if you have an IPv6 connection to the Internet, a couple of the packages will not download properly as the host servers seem to have properly configured IPv4 web services, but improperly configured IPv6 services. Specifically, the jquery-validation plugin will download an invalid archive and cause your build to fail. I had to disable IPv6 support on my build host to get this to download properly. It is unlikely that many of you will currently run into this problem as IPv6 is not very widely deployed yet.
At this point, you should have a CentOS/Red Hat/Scientific Linux 6 system online with a /devel/coyote directory created.
Next, download the following archive: (Link not yet available)
Extract this archive inside of the /devel/coyote directory. This will set up the basic build environment for Coyote 4. The directory structure inside the archive should produce something that looks like this:
To make sure you have access to and can download all of the necessary source packages, issue the following commands from within the /devel/coyote directory:
At this point, all of the source packages should be downloaded and ready to be compiled. The four build root environments (boot-output, devsys-output, root-output, and cdrom-output) each build a separate part of the Coyote Linux distribution. You will need to compile each of these build roots individually. This process will take multiple hours even on very fast hardware.
NOTE: Since each of the buildroot build processes ultimately ends up generating an identical cross-compiler toolchain, I will eventually add a process to greatly reduce build times by only requiring the toolchain portion of the compiles to be performed a single time. For now, I am concentrating on getting the custom software written to for hardware detection, firmware pre-loading/staging, and the web administration site.
For now, you will need to the individual build processes. Change into each of the following directories (in the order indicated) and issue the command “make”:
The final build (devsys-output) will, by far, take the longest to complete; however it is not required to create a functional Coyote Linux installer CD. The devsys tree creates a VMWare hard drive image which can be used with VMWare Workstation or VMWare player to boot into a build environment which is capable of producing executable to run on Coyote. It is not possible to simply compile applications on your primary build host as Coyote Linux does not use a compatible set of core system libraries and uses a Linux 3.2 kernel (CentOS still uses a 2.6 kernel). ?áAs a product of the VMWare image creation, a target directory is also created which can be chroot’ed into in order to compile software for Coyote. This process is outside of the scope of this page, but will eventually be documented.
As of the writing of this document, only 32 bit output builds are supported. However, the process used to compile Coyote Linux is capable of targeting multiple different architectures. I personally only have x86 based hardware to test with – as such, 32 bit (and eventually 64 bit) x86 builds will likely be the only “official” releases of Coyote Linux 4.0.
I will have the forums back online soon if I can come up with a solution that successfully keeps the spammers at bay.