Previous INDEX Next
Inaccessible Windows Workgroup Upgrading to FreeBSD 7.1

Upgrading to Debian Lenny

Debian Lenny was released on 14th February, 2009, so the following weekend I started to upgrade the various etch installations I have. There are two under VMWare on laptops, two native desktop and one native laptop instances.

Lenny upgrade under VMWare

I followed the Lenny release notes, which worked flawlessly. I ignored the advice to use aptitude and used apt-get instead. However, once I rebooted using the new 2.6.26 kernel, it did not see the hard drive (/dev/sda). This was due to the old version of VMWare I was using. I upgraded from VMWare 1.0.3 to 1.0.6 and the emulated hard drive was recognised by the new kernel.

Lenny upgrade on the desktop

The upgrade to lenny was very similar for my two desktop machines, gold and chrome. Gold is a home-built machine, based on an ABIT motherboard, from 2003. However, chrome is Dell Dimension p100t from circa 1997, with a 486 processor, which led to a problem later. I tackled gold first, as it is my main machine. Lilo was the boot loader on both machines and, given that the upgrade notes indicated there might be problems with the use of Lilo (the default settings for initramfs will create an image too large for Lilo to load), I took the opportunity to switch to grub prior to the upgrade.

First, I ensured that /etc/apt/sources.list pointed to etch and not stable, then made sure etch was completely up-to-date:

  apt-get update
  apt-get upgrade

Next, installed grub:

  apt-get install grub

Then created the default grub directory /boot/grub and ran update-grub to create the initial menu.lst file. On one system, the default groot had to be changed as the Debian root partition was the second partition on the drive. In addition, a Windows 2000 boot stanza was added:

  # groot = (hd0,1)
  
  title Windows 2000
  rootnoverify (hd0,0)
  makeactive
  chainloader +1

To ensure that the grub menu file was updated automatically as kernels were added or removed, the following lines were placed in /etc/kernel-img.conf:

  postinst_hook = update-grub
  postrm_hook = update-grub
  do_bootloader = no

Grub was installed on the MBR by:

  grub-install /dev/hda

Once this was tested, the old Lilo could be removed:

  apt-get remove lilo

The final piece of preparation was to clean out any old package files from the package repository under /var:

  apt-get clean && apt-get autoclean

The /etc/apt/source.list file was changed to point at lenny:

  deb ftp://ftp.uk.debian.org/debian/ lenny main contrib non-free
  deb-src ftp://ftp.uk.debian.org/debian/ lenny main contrib non-free
  deb http://security.debian.org/ lenny/updates main

OK, ready to go, so updated the package index files:

  apt-get update

Next, as advised, attempted to upgrade apt itself first:

  [root@gold:~]# apt-get install apt
  Reading package lists... Done
  Building dependency tree... 62%
  Building dependency tree... Done
  Some packages could not be installed. 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.

  Since you only requested a single operation it is extremely likely that
  the package is simply not installable and a bug report against
  that package should be filed.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
  apt: Depends: libc6 (>= 2.7-1) but 2.3.6.ds1-13etch9+b1 is to be installed
  Depends: libstdc++6 (>= 4.2.1) but it is not going to be installed
  E: Broken packages
  [root@gold:~]#

Bugger. This didn't happen with the first lenny install. I decided to try with aptitude instead, with more success. Aptitude was upgraded, and pulled in the packages mentioned in the upgrade notes (and a few more beside).

The next stage was to upgrade those packages that did not require new packages to be installed:

  aptitude search "?false" # convert aptitude's installed list for use with apt
  aptitude upgrade

This too, ran successfully, except that you need to ensure any NFS mounts are unmounted before this step. If you don't (as in my case), the upgrade process will complain and wait for you to umount the offending drives.

OK, the final phase:

  aptitude dist-upgrade

Aptitude listed a lot of packages but I hit "Y" and let it run. Returning a little while later, I was concerned to see that the disk space in /usr was nearing the limit (2GB). That wasn't good. Perhaps it had to do with the mass of texlive packages that were being installed that I didn't want? As I feared, towards the end of the dist-upgrade process the /usr partition became full. I noted a couple of failures to install packages but, as by this time, most activity was in /etc the damage didn't look too bad.

Once the dist-upgrade had finished, there was one additional problem to deal with. The exim4 upgrade had borked:

  Stopping MTA for restart:DEBCONFsomethingDEBCONF found in exim
  configuration.
  This is most probably caused by you upgrading to exim4 4.67-3 or
  later without accepting the suggested conffile changes. Please read
  /usr/share/doc/exim4-config/NEWS.Debian.gz for 4.67-2 and 4.67-4
   2009-02-24 15:37:10 Exim configuration error in line 28 of
  /var/lib/exim4/config.autogenerated.tmp:
    malformed macro definition
  Invalid new configfile /var/lib/exim4/config.autogenerated.tmp, not
  installing /var/lib/exim4/config.autogenerated.tmp to
  /var/lib/exim4/config.autogenerated
  invoke-rc.d: initscript exim4, action "restart" failed.

Well, I wasn't going to deal with that now, so I removed exim4 and all its works by:

  apt-get autoremove exim4 && apt-get purge exim4

The first part of recovery was to remove all the packages I did not need, that's everything related to tetex and texlive. That got me back to just under 1GB free. Secondly, I wanted to reinstall everything remaining to ensure it was installed correctly:

  aptitude -y reinstall `dpkg -l|grep ^ii|awk '{print $2}'`

I let this run overnight. The log file revealed a number of packages that could not be re-installed due to the fact there were old packages left over from previous releases. These I could safely remove from the system, except:

  linux-image-2.6.24-etchnhalf.1-686 # need a working kernel!
  msttcorefonts
  xfonts-artwiz

At this point I could reinstall exim4 and re-configure it, although leaving out the specials for local network mail delivery.

I then installed the lenny 2.6.26 kernel linux-image-2.6.26-1-686 and rebooted to check that everything was OK. The only thing I did not like was the new default option to print an elapsed time against the kernel messages. This can be removed by setting the following default parameters in the /boot/grub/menu.lst file:

  # kopt=root=/dev/hda2 ro printk.time=0

The last part of the upgrade was to add the new syslog function:

  apt-get install rsyslog

Now that one desktop was upgraded, I turned my attention to chrome. Here, I had the same problem as described above when attempting to update apt, i.e broken dependencies with libc6. This time, I tried a different tack, sticking with apt-get and trying to install the packages it was complaining about:

  [root@chrome:~]# apt-get install libc6 libstdc++6
  Reading package lists... 
  Building dependency tree... Done
  The following extra packages will be installed:
   binutils cpp cpp-4.1 cpp-4.3 gcc gcc-4.1 gcc-4.1-base gcc-4.3 gcc-4.3-base
   itcl3.1 libgcc1 libgmp3c2 libgomp1 libmpfr1ldbl libmudflap0 libncurses5
   libselinux1 libslang2 locales tcl8.3 tzdata util-linux util-linux-locales
  Suggested packages:
   binutils-doc cpp-doc gcc-4.1-locales gcc-4.3-locales gcc-multilib
   automake1.9 gcc-doc gcc-4.1-multilib gcc-4.1-doc gcc-4.3-multilib
   libmudflap0-4.3-dev gcc-4.3-doc libgcc1-dbg libgomp1-dbg libmudflap0-dbg
   glibc-doc libc6-i686 tclreadline dosfstools
  Recommended packages:
   libgpm2
  The following packages will be REMOVED:
   g++ g++-2.95 g++-4.1 itcl3.1-dev libc6-dev libmudflap0-dev libssp0
   libstdc++2.10-dev libstdc++6-4.1-dev libtool tcl8.3-dev
  The following NEW packages will be installed:
   cpp-4.3 gcc-4.3 gcc-4.3-base libgmp3c2 libgomp1 libmpfr1ldbl
  The following packages will be upgraded:
   binutils cpp cpp-4.1 gcc gcc-4.1 gcc-4.1-base itcl3.1 libc6 libgcc1
   libmudflap0 libncurses5 libselinux1 libslang2 libstdc++6 locales tcl8.3
   tzdata util-linux util-linux-locales
  19 upgraded, 6 newly installed, 11 to remove and 352 not upgraded.
  Need to get 25.1MB/26.0MB of archives.
  After unpacking 18.1MB disk space will be freed.
  Do you want to continue [Y/n]? 

That update worked OK, so I tried to upgrade apt again:

  [root@chrome:~]# apt-get install apt
  Reading package lists... 
  Building dependency tree... Done
  The following extra packages will be installed:
   apt-utils aptitude dpkg dpkg-dev libapt-pkg-perl libcwidget3 libdb4.6
   libept0 liblocale-gettext-perl libncursesw5 libtext-charwidth-perl
   libtext-iconv-perl libtimedate-perl libxapian15 lzma perl perl-base
   perl-modules
  Suggested packages:
   apt-doc python-apt debtags debian-keyring libcwidget-dev xapian-tools
   perl-doc libterm-readline-gnu-perl libterm-readline-perl-perl
  Recommended packages:
   aptitude-doc-en aptitude-doc libparse-debianchangelog-perl build-essential
   libgpm2
  The following NEW packages will be installed:
   libcwidget3 libdb4.6 libept0 libtimedate-perl libxapian15 lzma
  The following packages will be upgraded:
   apt apt-utils aptitude dpkg dpkg-dev libapt-pkg-perl liblocale-gettext-perl
   libncursesw5 libtext-charwidth-perl libtext-iconv-perl perl perl-base
   perl-modules
  13 upgraded, 6 newly installed, 0 to remove and 339 not upgraded.
  Need to get 20.0MB of archives.
  After unpacking 16.2MB of additional disk space will be used.
  Do you want to continue [Y/n]? 

OK, much better. Now the upgrade was back on track. Everything else proceeded as normal, and no massive texlive install occured. Of course, that may have be due to cruft left over on gold. However, even chrome had some stuff installed I didn't want, e.g. X11, sane and the avahi daemon.

Following the completion of the upgrade, I cleaned-up the packages using apt-get autoremove:

The upgrade had automatically installed the lenny kernel, 2.6.26, so I confidently rebooted into it. Ulp, no IDE devices:

[   21.065487] Uniform Multi-Platform E-IDE driver
[   21.065749] ide: Assuming 33 MHz system bus speed for PIO modes; override with idebus=xx
[   22.320593] PIIXa: IDE controller (0x8086:0x122e rev 0x02) at PCI slot 0000:00:01.0
[   22.321073] PIIXa: bad irq (0): will probe later 
[   22.321259] PIIXa: IDE port disabled 
[   22.321401] PIIXa: IDE port disabled 

More worryingly, when I attempted to boot using the latest etch kernel, linux-image-2.6.18-6-486, installed as part of the final etch upgrade, that produced the same problem. Was their some co-incidental hardware problem? No, because moving back to linux-image-2.6.18-5-486 booted OK. This problem has already been reported.

Debian lenny upgrade on a laptop (steel)

My last upgrade was to the old Toshiba Satellite 4060 XCDT laptop, steel. This did not manifest the same problem as the two server machines when trying to upgrade apt as the first step. My theory is that both gold and chrome had been previously upgraded from sarge to etch, as the two machine with no apt issue had been fresh etch installs.

Apart from having to fix up the exim4 configuration after the upgrade, there were two weird issues to deal with on steel, post-installation.

The first was generated by apache2, a message of the form:

  apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

After a bit of digging around, this turned out to be a FAQ on the apache web site. The issue can be solved by either:

The second problem was intermittent. Sometimes, on boot, steel would hang, for about three minutes, just after printing the fsck messages:

  Checking all file systems.
  /dev/hda8: clean, 10667/3662848 files, 381431/7323624 blocks
  /dev/hda9: clean, 4475/4833280 files, 4400887/9649032 blocks
  /dev/hda6: clean, 13/122880 files, 26056/489948 blocks
  /dev/hda2: clean, 47825/488640 files, 254580/975948 blocks
  /dev/hda5: clean, 79/366528 files, 29122/732957 blocks
  /dev/hda7: clean, 5485/244320 files, 271041/487966 blocks

There was nothing I could find about this via Google. In an attempt to gather further information, I changed the default in the /etc/default/rcS script to VERBOSE=yes. Of course, the problem does not now occur. I have no idea what the problem is, but at least I have a fix.

Addendum - 3rd March, 2009

I noticed there were other anomalies with steel; sometimes the sound card would not be detected by alsa, and the fan would come on, never to stop. I messed around with toshiba_acpi module, which allowed me to turn off the fan with:

  echo "force_on: 0" >/proc/acpi/toshiba/fan"

However, the fan would always come back on, even when the CPU was idling. I finally turned off acpi on the lenny kernel, 2.6.26, as seemed to be the default with the old etch kernel 2.6.18, by adding acpi=off to the kernel boot line. Instant sane behaviour; none of the problems recurred, including the hang on fsck with VERBOSE=no in /etc/default/rcS.

Previous INDEX Next
Inaccessible Windows Workgroup Upgrading to FreeBSD 7.1