Sudo and package manager – updating an old Linux system pt.2

The previous post introduced ConnochaetOS, a nice i586 Linux-libre desktop distro which is now dead. Not having received any updates for a long time makes it the ideal target for a little (?) exercise: Updating an old Linux distro which has missed a lot of important changes!

While the previous post showed how to install, update to the most recent (albeit very old) versions available on the repos and change the filesystem to today’s (Arch Linux) layout, we’re going a little bit deeper today by doing some package building and manual updating. The goal is to build newer packages of some important programs which can then be used to further update the system.

It’s only 5 packages today – but I show the package building process in detail here so that even people new to this can easily follow it. Also the next part can then be much shorter.

Package building on Arch-derivatives

With ConnOS being an Arch-derivative, there are fortunately a great many of PKGBUILDS available for most of the programs relevant for us. Most of them can be downloaded from archlinux.org or the Arch User Repository (AUR). When it comes to completely free software replacements (like Linux-libre, a modified kernel without any binary blobs and such) there’s parabolagnulinux.org, another fine source.

With these two alone we already have a great resource which almost completely satisfies our needs. Most of the package build recipes need to be modified for use with ConnOS, primarily because both distributions are not targeted at i586 machines. However this is usually a simple thing to do.

Generally arch=(‘any’) PKGBUILDs will work without modifications if all the dependencies are available on ConnOS. If they are not, it may be desirable to modify them and drop some dependencies which may not be worth the effort. All other recipe files need to be modified to make the i586 architecture available and often to add –host=i586-pc-linux-gnu and –build=i586-pc-linux-gnu to the configure parameters, too.

In many cases this is already all there is to do and package building can begin. The more interesting part is to understand which packages should be updated – and in which order. This is not always clear. And the really tricky part is finding out what to do in case any technology leaps occurred and there isn’t simply a newer version of some package available but a whole new application (which works differently) has replaced it. However this won’t be the case in this part of the updating series.

But enough of the theoretical talk – let’s get started!

Filesystem related updates

I’ll describe what I did to update ConnochaetOS here – including downloading the PKGBUILD files (but not my modifications to them in detail). If you also want to update ConnOS, you can save yourself some time and download my update pack which contains the modified PKGBUILDs I use here.

ConnOS with the “new” kernel

Alright. We have a system which runs on top of the “new” 3.2 kernel and uses the new filesystem layout now. First I create a new src directory and a subdirectory called iana-etc in my user’s home. Then I use links to go to http://www.archlinux.org/packages/, search for iana-etc and download both files needed to create the package.

Getting the PKGBUILD with links

Since the version of links available is very old, it doesn’t cope well with compressed files. Both PKGBUILD and newer.patch are gzipped files. And thanks to gzip being an incredibly stupid program (behaving like a Windows application!) we need to add the .gz extension to both files so that we can decompress them…

Building the package

Then we’re set and can begin building the package with makepkg. If all goes well (and it should) we’re left with a new package called iana-etc-2.30-3-any.pkg.tar.xz. After we become root (with su) we can install it using the pacman -Uf command (“f” is for force and allows pacman to overwrite files currently installed by other packages). Pressing CTRL+D (or typing exit) we leave the root shell since packages should in general not be built with root privileges.

Forcefully updating the package as root

The next package is called filesystem (which could not be installed if we hadn’t adapted our filesystem’s layout to the new one in the previous post). I create a directory for it, download all the required files and decompress them.

Links again

While you can at least use wildcards with gunzip, this is not possible when renaming the files. Since there are quite a lot of them in case of this package, the for command comes in handy (for file in *; do mv $file $file.gz; done).

It should actually be adapted to ConnOS, but then again it won’t hurt anybody if some of the installed files say “Arch Linux”, right? Also I simply disabled the manpage part of it – this saves us from building the package asciidoc first and I don’t think that it would be worth our time.

Renaming files and package building

Building and installing (after becoming root) is just the same as above. This package must also be installed with the “f” switch enabled since it needs to override some already existing files which were not part of the old filesystem package. We’ll ignore the warnings and errors right now.

Modernizing a few system components

Next we have to take care of one of the biggest drawbacks with ConnOS: The unavailability of sudo! Creating a new dir for it, downloading the files, renaming and decompressing is nothing new anymore. But since we’re building a package now that contains binaries, the PKGBUILD from Arch needs to be modified. Afterwards the new package can be installed as root (for the last time now). Then only the file /etc/sudoers needs to be changed so that the new user is allowed to use sudo to temporarily gain root privileges.

Adding the normal user to the sudoers file

Now it’s a good idea to update pacman. The most important reason is because the old version ConnOS has cannot understand some important things which many new PKGBUILDs rely on (like e.g. the options variable or the prepare() function). Downloading and building is more or less like before and the modifications include disabling the depends since the PKGBUILD claims pacman to need newer versions of bash, curl and others which is not quite the case. Also some architecture related changes have to be made.

Upgrading pacman

Installing pacman is now a lot more convenient since we can use sudo from now on (no more su!). After upgrading it, the package database must be converted to the new format and the repositories should be updated, too.

The next one is a mere convenience update: Links. The version that comes with ConnOS works well enough but updating it means no more messing with gzipped files. So from my point of view it’s well worth it.

Upgrading links

So now ConnOS is in a state where it is much more pleasant to work with. Still this is just one little step compared to all the work that would have to be done to fully update the system.

What’s next?

Describing package building at length took more space than I had anticipated. So the next post will deal with a very important process: Updating the compiler toolchain!

Advertisements

ConnochaetOS – An example of updating an old Linux system pt.1

Surprise, surprise! Today we have a topic very different from what I guessed it to be. I’m going to write about the process of updating an old Linux system (which is in fact rather challenging due to the fact that so many things changed in the time that has passed).

Updating an old Linux system can be quite adventurous (seriously!). If you’ve never done it there’s quite a bit you can learn from the process. This post is in fact more or less just an introduction. It describes installing the system (ConnochaetOS) and making some preparations.

ConnochaetOS

This would probably have remained a little personal experiment but I wanted to dedicate this post to the memory of ConnochaetOS – an Arch-based GNU/Linux-libre distro with eglibc which was made with older PCs (i586) in mind. It has been a great distro but has been inactive for a long time. A few month ago the maintainer finally decided to shut down the project. While this didn’t really come unexpected, it still is a pity.

Well, there’s one very important sentence in Haary’s post: Of course everyone is welcome to overtake and to fork.


The ConnochaetOS logo

So far it doesn’t look like somebody will do this, though. I would consider to take it over – but then again I don’t feel that I have the knowledge needed for such a project just yet. Also there’s EERIE/ELDER to work on and while it’s going in a somewhat similar direction there are of course quite a few differences in design. Still I’d like to show how a system like ConnOS can be (partly) updated to become a more modern Linux system.

Installing the system

Currently all the files from the project are still accessible but will be removed at the end of the year. You can download the ISO directly from SF.

The ConnOS installer

ConnochaetOS comes with a very simple but friendly installer. It lets you choose how to install and then simply does the rest of the show.

Preparing the kernel images

Unlike Arch, ConnOS never was a rolling-release distro. For that reason the system packages are not downloaded from the net but installed from cd. This is actually a good thing since it enables you to install the system on old machines without access to the internet, too.

The installer finished

Once the installer is done, just reboot and you should be able to log into your “new” ConnOS system!

Starting and updating

ConnochaetOS is a desktop distribution so you will be greeted by a graphical display manager. After the login ConnOS provides us with a simple, light-weight wm (iceWM) which is quite nice.

The ConnOS login screen

First it’s of course a good idea to install any updates available from the distro’s repositories. Since there’s no sudo installed we have to do this the old-fashioned way and use su to become root. Now we have the chance to start updating.

Updating the system with pacman

There are not too many updates available (and these are pretty old, too, but installing them surely doesn’t hurt).

While ConnOS 0.9.1 comes with a 2.6.32 (lts) kernel it also has a 3.2 (“current”) kernel available. Of course we’re going to uninstall the 2.6 one and replace it with the 3.2 kernel!

Updating the kernel

Following the kernel update we’re left with a broken system for the moment. This means that rebooting now would be a bad idea. For that reason we’re going to edit /boot/grub/menu.lst and point the boot manager to the new kernel image.

Modifying the boot loader config

This is as far as we can update the system with already existing binary packages. We’ll have to do the rest by hand! To be able to do so we first need to install the development tools.

Installing development tools

Filesystem change

One of the big things that happened after ConnOS fell dormant was a change of the filesystem layout in Arch. Since all current package recipes are expecting the system to follow the new way, we’re converting our system to the new standard.

As this involves moving important system executables it cannot be done while the system is running. We’ll have to use an external live system to be able to manipulate our ConnOS installation according to what we’re up to. Unfortunately I have not been able to get this done with ConnOS’s own installation image. But pretty much any live distro should do the trick.

Making changes to the filesystem

I’ve booted into an Arch install system. Doing the changes is actually pretty simple:

  1. we need to mount the system partition
  2. we move all the files from lib to usr/lib
  3. we move all the files from bin and sbin to usr/bin
  4. we remove the directories lib, bin and sbin
  5. we create new symlinks instead which point to the new locations
  6. we modify GRUB’s menu.lst again, appending init=/usr/bin/init to the kernel line

Notifying GRUB on where init resides

So far for our preparations. Now at this point we have a ConnOS system which is ready to receive some manual updating!

What’s next?

Part two of the updating example will deal with building packages to update a few important system components and building an up-to-date toolchain (for compiling even more updated packages ;)).