Upgrading Debian sarge to etch

Following the recent release of Debian 4.0 (etch), I decided to upgrade my backup server, chrome, which was running sarge. My last experience of a Debian upgrade was very good, so my expectations were high.

I followed the instructions in the Release Notes, which went fine until section 4.5.4.2:

First, check whether you have the libfam0c102 and xlibmesa-glu packages installed.

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

It looked like I had both of these, so I went ahead and followed the next upgrade step:

# aptitude install x11-common libfam0 xlibmesa-glu

Then I got this:

  Reading Package Lists... Done
  Building Dependency Tree       
  Reading extended state information       
  Initializing package states... Done
  Reading task descriptions... Done  
  Some packages had unmet dependencies.  This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.

  The following packages have unmet dependencies:
  libfam0c102: Conflicts: libfam0 but 2.7.0-12 is to be installed.

I found some advice on the net that this could be fixed by issuing:

  aptitude install libfam0=2.7.0-12 

So that's what I did. That seemed to work ok, so I tried to repeat the above step, but missing out libfam0:

  # aptitude install x11-common  xlibmesa-glu
  ...
  Errors were encountered while processing:
    libgconf2-4
    liborbit2
    gconf2

It was late, I was stupid; I pressed on regardless...

  # aptitude install linux-image-2.6-486 
  Errors were encountered while processing:
    libgnome2-common
    metacity
    libgnomevfs2-common
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  Ack!  Something bad happened while installing packages.  Trying to recover:

Uh oh. This didn't look good. I checked the status of X. Hmm, xserver-xfree86was still installed; perhaps that was the problem?

  # apt-get remove xserver-xfree86
  Reading Package Lists... Done
  Building Dependency Tree... Done
  You might want to run `apt-get -f install' to correct these:
  The following packages have unmet dependencies:
    libgnome2-common: Depends: gconf2 (>= 2.7.92) but it is not going to be installed
    libgnomevfs2-common: Depends: libbonobo2-0 (>= 2.8.0) but it is not going to be installed
                         Depends: libgconf2-4 (>= 2.8.1) but it is not going to be installed
                         Depends: libglib2.0-0 (>= 2.6.0) but it is not going to be installed
                         Depends: libgnomevfs2-0 (>= 2.8.3-7) but it is not going to be installed
                         Depends: liborbit2 (>= 1:2.10.0) but it is not going to be installed
                         Depends: libsmbclient (>= 3.0.2a-1) but it is not going to be installed
                         Depends: gconf2 (>= 2.8.0-1) but it is not going to be installed
                         Depends: shared-mime-info but it is not going to be installed
                         Depends: desktop-file-utils but it is not going to be installed
    metacity: Depends: libatk1.0-0 (>= 1.7.2) but it is not going to be installed
              Depends: libgconf2-4 (>= 2.8.1) but it is not going to be installed
              Depends: libglib2.0-0 (>= 2.4.7) but it is not going to be installed
              Depends: libgtk2.0-0 (>= 2.4.4) but it is not going to be installed
              Depends: libmetacity0 (>= 1:2.8.1) but it is not going to be installed
              Depends: liborbit2 (>= 1:2.10.0) but it is not going to be installed
              Depends: libpango1.0-0 (>= 1.6.0) but it is not going to be installed
              Depends: libstartup-notification0 (>= 0.7-1) but it is not going to be installed
              Depends: gconf2 (>= 2.6.2-1) but it is not going to be installed
  W: You may want to run apt-get update to correct these problems
  E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

Aaaaaaargh. At this point I gave up, planning to return to it when I was not tired and emotional.

A couple of days later I had enough time to revisit the upgrade. I first decided on following the suggestion of aptitude and run apt-get -f install. This suggested I remove pretty much all of X, but I didn't care as I was already considering it was more trouble that it was worth on a slow machine like chrome.

Unfortunately, at this point my memory is a little hazy. I think that is what I did, but I am not absolutely sure. Should have scripted the session, of course.

If my memory is correct, this appeared to do the trick. The removal of vast swathes of X packages finished normally, and I was able to run the aptitude dist-upgrade step without any problems.

Post Upgrade Work

Apache

I decided to replace my existing Apache 1.3 version with apache2 (Apache 2.2). Adapting to the new configuration setup was not too bad. Local configuration is placed in the /etc/apache2/httpd.conf file. For me, all this contains is:

  # DirectoryIndex: Name of the file or files to use as a pre-written HTML
  # directory index.  Separate multiple entries with spaces.
  #
  <IfModule mod_dir.c>
    DirectoryIndex index.html index.htm index.shtml index.cgi 
  </IfModule>

The new method of enabling sites took me a little while to figure out. I need to offer two site, one for hydrus and one for the, uh, other site. I used the apache NameVirtualHost * directive (conveniently provided by the defaultsite configuration file, and then added the virtual sites using VirtualHost directives as shown in the O'Reilly Apache (3rd Edition) book I own.

In /etc/apache2/sites-available, I created two files; the first fs:

  <VirtualHost fs.hydrus.org.uk>
    ServerName fs.hydrus.org.uk
    ServerAdmin www@hydrus.org.uk
    DocumentRoot /home2/www/fs/data/
    <Directory />
        Options SymLinksIfOwnerMatch
        AllowOverride None
    </Directory>
    ..other directives..
  </VirtualHost>

The other, hydrus, contained:

  <VirtualHost www.hydrus.org.uk>
    ServerName www.hydrus.org.uk
    ServerAdmin www@hydrus.org.uk
    DocumentRoot /home2/www/hydrus/data/
    <Directory />
        Options SymLinksIfOwnerMatch
        AllowOverride None
    </Directory>
    ..other directives..
  </VirtualHost>

Links are then created in the /etc/apache2/sites-enabled directory to the actual files, using a naming convention to ensure site configuration files are read in the right order. That is:

  cd /etc/apache2/sites-enabled
  ln -s ../sites-available/hydrus 001-hydrus
  ln -s ../sites-available/fs 002-fs

When starting apache, this produced these warnings:

  [warn] VirtualHost www.hydrus.org.uk:0 overlaps with VirtualHost fs.hydrus.org.uk:0, 
  the first has precedence, perhaps you need a NameVirtualHost directive

Well, I did have a NameVirtualHost directive. What was going on? It seems the setup as described in the O'Reilly book is wrong; the <VirtualHost> argument must not be a site name, but *, otherwise the warnings as shown above are issued. The actual sitenames are defined by the ServerName (and ServerAlias if required). Virtual sites should be defined something like:

  <VirtualHost *>
    ServerName fs.hydrus.org.uk
    ServerAdmin www@hydrus.org.uk
    DocumentRoot /home2/www/fs/data/
    <Directory />
        Options SymLinksIfOwnerMatch
        AllowOverride None
    </Directory>
    ..other directives..
  </VirtualHost>
  <VirtualHost *>
    ServerName www.hydrus.org.uk
    ServerAdmin www@hydrus.org.uk
    DocumentRoot /home2/www/hydrus/data/
    <Directory />
        Options SymLinksIfOwnerMatch
        AllowOverride None
    </Directory>
    ..other directives..
  </VirtualHost>

Of course, don't forget the NameVirtualHost * directive.

It took me a while to work out why user files were not being displayed; I had to activate this feature by:

  ln -s /etc/apache2/mods-available/userdir.conf /etc/apache2/mods-enabled/userdir.conf
  ln -s /etc/apache2/mods-available/userdir.load /etc/apache2/mods-enabled/userdir.load

Exim

I replaced exim (i.e. exim 3) by exim4. I'd hacked around with the configuration of exim to allow mails to be sent to machines on the local network. These additions needed to be included in the exim4.conf.template, but with a slight modification, as the transports of exim 3 are part of the router section. I had to add a condition to the locally defined router local_network to ensure that it was not used when the recipient was on the local machine.

Add this text to the top of the routers section of exim4.conf.template:

  # In the ROUTES section, a new router is defined, which handles
  # recipient addresses on local domain machines - anything ending in
  # the domain name, and unadorned host names (assuming they
  # contain no digits).  If the recipient does not match anything
  # in the domains value, the smarthost router will be used.
  local_network:
    driver = dnslookup
    transport = local_smtp
    domains = ! +local_domains : *.hydrus.org.uk:^[A-Za-z]*\$

And, add this text to the top of the transport section:

  # Define a transport for local machines. This performs
  # rewriting of the envelope (return_path) and headers to
  # indicate the mail is from chrome.
  local_smtp:
    driver = smtp
    return_path = ${local_part}@chrome.hydrus.org.uk
    headers_rewrite = *@hydrus.org.uk ${1}@chrome.hydrus.org.uk fr

You will need to replace the local host name (chrome) and domain name (hydrus.org.uk) as required for your site.

Support for parallel printer port

Printing had stopped working on the newly etched chrome. There was no /dev/lp0. At first I suspected some arcane udev problem, but it turned out to be solved by adding lp to /etc/modules.