Ubuntu Kickstart Installs and Corrupt Packages File

When installing Ubuntu Lucid via Kickstart, you may run into the error:

Debootstrap warning http://server/ubuntu/lucid/dists/lucid/restricted/binary-amd64/Packages was corrupt

The problem is that the Ubunutu installer tried to decompress a file Packages.gz from that directory, and the result was a zero-length file. This result is being interpreted as a corrupt file.

To fix this, all that needs to be done is to unpack the Packages.gz file on the server end. With an unpacked Packages file, the Ubuntu installer retrieves the zero-length file from the server instead of getting it by unpacking Packages.gz – and it does not interpret the zero-length Packages file as corrupt.

If you are using a mounted Lucid Lynx CDROM, then you need to use a bind mount in order to supersede the mounted read-only directory with a fixed directory. Create a new directory and copy the contents of the appropriate directory into it – the directory containing Packages.gz.

Unpack Packages.gz, and mount the resulting “fixed” directory using bind:

UB=/var/www/ubuntu mount --bind $UB/lucid.bugfix $UB/lucid/dists/lucid/restricted/binary-amd64

This will take care of the problem. Hats off to Sascha Kauffman, from whose article I learned this solution.

Unattended Ubuntu Installations

Michael Reed wrote a nice tutorial for Linux User and Developer about unattended Ubuntu installations. Ubuntu aso has excellent documentation on the booting process.

Unattended installations are a boon to system administrators, or anyone who needs to install systems several times a month or so.

When an installation is preconfigured – especially using the network – an administrator can start the installation then go do something else. Productivity increases dramatically. If you have many systems to install – you can start all of them and leave them to finish on their own while you complete other tasks.

An unattended installation also leads into systems being identically configured, providing for easier administration and easier debugging. If systems are hand-crafted, then replicating the system (such as hardware upgrades or restores) will be harder – or more likely, impossible.

Since Ubuntu is based on Debian, the original preseed configuration tool is available; however, the excellent kickstart (and anaconda) program from Red Hat was adapted to Ubuntu. Preseed handles more options, but kickstart offers its own advantages as well. They can be used together for installations.

A whitepaper from Canonical (Automated Deployments of Ubuntu, by Nick Barcet in September 2008) describes in easy-to-read detail all the possibilities of unattended installations with preseed and kickstart. While the whitepaper discusses these things in context of Ubuntu 8.04, it is still a valuable resource in concert with the official Ubuntu install documentation.

The files required for booting from the network are available from Ubuntu mirrors; be sure to get the right one for your architecture and Ubuntu version (this discussion assumes ix86 and Ubuntu Lucid Lynx).

An abbreviated description of the process to set up for kickstart is this:

• Set up an HTTP server (web server).
• Set up a DHCP server.
• Set up a TFTP server.
• Set up a NFS server.

Once these three servers are up, you are more than half-way there. The kickstart file will be placed on the web server for the unattended installations.

Configure the DHCP server to use the pxelinux.0 file for the boot loader, and from the appropriate TFTP server. The boot files have to be located on the TFTP server in the appropriate locations.

Make sure, too, that all of the files necessary for installation – the entire distribution – is available via NFS or via the Internet. Once the boot loader is started, and the Linux kernel is loaded, all of the packages will be downloaded from this source.

Best thing to do is to test the autoinstalls on a virtual machine if possible, a scratch machine if not – and test until the installs are clean and unattended. Do this before your boss says you need to get that install done pronto!

Check the documentation for details; I’m currently setting up Lucid Lynx and will provide complete details later.

Automation: Live and Breathe It!

Automation should be second nature to a system administrator. I have a maxim that I try to live by: “If I can tell someone how to do it, I can tell a computer how to do it.” I put this into practice by automating everything I can.

Why is this so important? If you craft every machine by hand, then you wind up with a number of problems (or possible problems):

• Each machine is independently configured, and each machine is different. No two machines will be alike – which means instead of one machine replicated one hundred times, you’ll have one hundred different machines.
• Problems that exist on a machine may or may not exist on another – and may or may not get fixed when found. If machine alpha has a problem, how do you know that machine beta or machine charlie don’t have the same problem? How do you know the problem is fixed on all machines? You don’t.
• How do you know all required software is present? You don’t. It might be present on machine alpha, but not machine delta.
• How do you know all software is up to date and at the same revision? You don’t. If machine alpha and machine delta both have a particular software, maybe it is the same one and maybe not.
• How do you know if you’ve configured two machines in the same way? Maybe you missed a particular configuration requirement – which will only show up later as a problem or service outage.
• If you have to recover any given machine, how do you know it will be recovered to the same configuration? Often, the configuration may or may not be backed up – so then it has to be recreated. Are the same packages installed? The same set of software? The same patches?

To avoid these problems and more, automation should be a part of every system wherever possible. Automate the configuration – setup – reconfiguration – backups – and so forth. Don’t miss anything – and if you did, add the automation as soon as you know about it.

Things like Perl, TCL, Lua, and Ruby are all good for this.

Other tools that help tremendously in this area are automatic installation tools: Red Hat Kickstart (as well as Spacewalk), Solaris Jumpstart, HP’s Ignite-UX, and OpenSUSE Autoyast. These systems can, if configured properly, automatically install a machine unattended.

When combined with a tool like cfengine or puppet, these automatic installations can be nearly complete – from turning the system on for the very first time to full operation without operator intervention. This automated install not only improves reliability, but can free up hours of your time.