Cradle to Grave – A Look at Arch Linux

I have upgraded my systems around 30 times with new versions. In the office, I use Ubuntu, and I also keep abreast of SUSE and Mandriva. However, all these distributions have one feature in common— they get updated twice a year, with a lot of excitement and curiosity generated around each new version. However, over the last few years, I’ve found that while I want the new capabilities, the process of upgrading is too disruptive.

I was very comfortable with the OS that came with the Eee PC 701. It booted fast, and had all the functionality I needed once I installed VLC and could play x.264 videos. After over two years, I finally had to change and replace it with Ubuntu Netbook Remix as I wanted to explore new browsers,particularly, Mozilla Fennec. Switching a distribution was easier than making the new browsers run with the old libraries. This triggered a train of thought—what if I wanted to create my own distribution. Should I base it on Debian,Ubuntu, Fedora or should it be something else. If something else, why? It is easy to create a custom spin with Fedora. I use it to create a live USB version that I use on an old system without a hard disk. Switching versions is not hard. The repository details need to be changed. But it is not transparent. It also needs all the virtually identical packages to be downloaded again.

If I create my distribution using the stable version, by the time I am ready to release it, the base has changed. Xandros had a new version out by the time I bought Eee PC, which continued to use the older version. The concept of a rolling distribution started to appeal to me. I was not looking to create an installation just for myself. I looked at the possibility of a system given to me with a pre-installed OS, which I could continue to use till the system dies. Hence, ease of installation was not an issue. Ease of updating packages was important.New releases of the major distributions provided a perfect excuse for me to experiment. A new version of X.org appeared with a new version of the Intel graphics driver. A very nice improvement unless one was working with old hardware, in which case the display often froze. The option now was to reinstall older distributions or look for a feature that would allow selective downgrading of packages. At some point, support for old hardware has to go. However, I did not want to sacrifice the benefits of the new packages.

Arch Linux—the first steps

My father would painstakingly type out an e-mail taking half an hour, and then the display would freeze; this was after I had upgraded my parents’ machine to Fedora 12. I felt this was the perfect opportunity for me to explore Arch Linux. I followed the instructions on the Arch wiki. Installation is pretty straightforward though not trivial. It needs some knowledge of Linux packaging.

Using the package manager, pacman, was similar to using Yum on Fedora. Installation of the applications my parents needed was not difficult, since I knew the package names.Arch Linux also uses the current versions of X.org and Intel drivers. The display issues on my parents’ system were even worse with Arch Linux. One can easily downgrade a package by installing a lower version from /var/cache/pacman/pkg. However, since this was the initial installation,this was not an option.

As expected, forums provided an answer. One post had given links to five packages that needed to be replaced to use an older version of X.org and the Intel driver on the old hardware. The problem with the Intel legacy driver is that one can’t switch from the graphical environment to the console environment. That means, Ctrl-Alt-F1, etc, will not display a usable console. While this may be irritating for me, I was sure my parents would never need it.

The Arch Linux wiki prominently mentions the option to specify the list of packages to exclude from an update. I added these packages to the pacman.conf file, as follows:

IgnorePkg = xorg-server xf86-video-intel-legacy xf86-input-evdev xf86-input-synaptics intel-dri

I subsequently had to add a sixth package to the list, libgl. I then found that the Yum configuration file also has a similar option.My parents’ system has been current since then and has not had a problem with video freezing. One of the major changes so far is that the system had Thunderbird 2 when I installed Arch Linux; now, it has Thunderbird 3. And the system is now using the 2.6.32 kernel.

The only misstep was that I installed the Go-oo (gooo.org) OpenOffice.org version, which had problems with templates. Forum posts led me to the openoffice-base as the alternate option. I then needed help to get the spell-check to work. The dictionaries are included in the distribution in /usr/lib/openoffice/share/extension/install/. But the desired ones have to be installed using the OpenOffice.org’s ‘Extension Manager’ under the Tools menu.

I had problems getting PulseAudio sound to work for normal users. Finally, I’ve made them a part of the ‘audio group’ till I sorted out the permissions issue. I copied a couple of directories from the Fedora distribution: /usr/share/icons/Fedora and /usr/share/themes/Fedora. This resulted in the desktop looking about the same in Arch Linux as it did on Fedora, and minimised the impact of the change on my parents.

Replicating Arch Linux

In case the systems are identical, we can create a dump of a disk image and restore it on other systems. However, I wanted to try to replicate the environment on another old system that was similar but not identical.
I took a tar back-up of the root partition of my parents’ computer, with a plan to restore it and see the minimum changes needed to make the new system functional.The experience turned out to be harder than I expected.I restored the tar back-up on an empty partition. Changes needed to be made in fstab to use the correct partitions for the root and home. Grub configuration needed changes in order to use the correct UUID of the root disk. After some effort, the system started to boot, but the kernel would crash. I reinstalled the kernel to make sure that a fresh kernel image was built, but the kernel panic would not go away.

The next step was to install the minimum Arch Linux and then restore the back-up. I made the necessary changes to the fstab and Grub configuration files. I had saved the installed kernel and kernel image and restored them. This time, the system booted and worked fine. It was perfect until I tried to install the network manager to use the USB Reliance NetConnect. pacman complained. I forced it to ignore the problems and, soon, had an unusable system.

Arch Linux uses files to maintain the state of the installed and available packages in local and sync directories in /var/lib/pacman/. Since I restored the tar back-up, the directories now had the original files and the updated files. The result was a very confused package manager.

So, my third attempt was to install core Arch Linux. This time, I removed the local and the sync directories before restoring the back-up. As before, I had saved copies of the installed kernel and image files, and restored them. Although some extra files probably remained on the system, it did not create any problems. The system has been working fine. In retrospect, it would be much easier to create a script that will install the desired packages after the core installation—much like having a kickstart file on Fedora.

Arch Linux for organisations?

I hope to return to this topic after another six months, when new versions of Fedora and Ubuntu are out and I have played around with Arch Linux updates over the major changes as well.Organisations crave for continuity. The cradle-to-grave time frame for an organisation is longer than the lifespan of any workstation. Solutions like RHEL work well for servers in an organisation. The same model is not suitable for desktops,where the requirements keep changing all the time.

If an organisation has internal skills, Arch Linux may very well be an ideal distribution to use. The admin staff can maintain a single repository. They can have a script for installing the desired applications on a fresh machine. Even though the command pacman -Syu to update the system is not hard to use, an organisation could offer a GUI to do so. Or the admin staff could make it a cron task.

If the organisation is a software development house, all the better. Developers could use virtual machines, with whatever distribution and version they need, to meet client needs. Each time a new machine is needed, an image could be created and stored on a central repository. A developer could get started with the desired image immediately, with negligible downtime.

One downside, which I mentioned earlier, is that the use of files to keep track of the packages—installed and available— is flaky. The second issue is the boot-up process, which does not use the init levels. It uses an rc.conf file, which is simple but different. I miss integrations like PulseAudio, the desktop on the major distributions and the friendly admin tools. I also miss the delta packages of Fedora.

Overall, though, I am enthusiastic about the possibilities Arch Linux offers and plan to continue experimenting with it. This article has been completed using the beta version of OpenOffice.org 3.2, which is available through the Arch Linux repository. Both the stable and the beta versions can be installed. It would be immensely valuable to me if users could try the new packages for features important for them and provide feedback.