Debian Squeeze was released on 6th February, 2011; a weekend or so later I upgraded the various Lenny installations I have. There are three native desktops and one native laptop instances.
I followed the Squeeze
release notes, which worked pretty much as advertised. Most of
my systems have PATA disks, and when the release notes warn you
(section 5.1.1) that device names and ordering will change, they
mean it. However, the upgrade scripts will add UUID-style disk
partition identification to /etc/fstab for you, so the
whole thing is relatively painless.
Gold is a home-built machine, based on an ABIT motherboard, from 2003. The only issues during this upgrade were:
The /var partition was too small to take the set of squeeze packages,
so I had to follow the advice given in section 4.4.3 of the release
notes and use a temporary /var/cache/apt/archives directory
from a filesystem with sufficient free space, using the mount
--bind command.
I followed the minimal system upgrade approach, that is:
# apt-get upgrade # upgrade those packages without removes/installs # apt-get install linux-2.6-686 # install new squeeze kernel # apt-get install udev # install matching udev
I then re-booted. Udev complained about use of the
deprecated SYSFS keyword in one of the rules
files, z60_xserver-xorg-input.wacom.rules, so I deleted the
file as the simpest fix.
The full upgrade was then started via apt-get
dist-upgrade. The only major issue here was the migration to a
dependency-based boot order. The dialog identified a number of
/etc files it didn't like (e.g. libdevmapper1.02) and also
recommended that a number of packages should be purged
(initrd-tools, klogd, libdevmapper, modutils, postgresql-7.4,
sysklogd). Once the upgrade was complete, I did as instructed,
ran dpkg-reconfigure sysv-rc and migration was successful.
The final issue was X related. I'd been using the nv
driver, but that now refused to load, saying:
(EE) NV: Kernel modesetting driver in use, refusing to load (EE) No devices detected.
nv is now deprecated.
The xserver-xorg-video-nouveau replaces it.
The only issue (which turned out not to be) was that during the kernel install, I saw warnings regarding firmware:
Package configuration Configuring linux-image-2.6.32-5-686 Required firmware files may be missing This system is currently running Linux 2.6.26-2-686 and you are installing Linux 2.6.32-5-686. In the new version some of the drivers used on this system may require additional firmware files: e100: e100/d102e_ucode.bin, e100/d101s_ucode.bin, e100/d101m_ucode.bin Most firmware files are not included in the system because they do not conform to the Debian Free Software Guidelines. You may need to reconfigure the package manager to include the contrib and non-free sections of the package archive before you can install these firmware
This puzzled me, as my sources.list file always include
contrib and non-free. I looked back through the log file of the
install and found that firmware-linux-free had been
installed, so I figured I could ignore this warning. On re-boot, I
had network access, so I was correct (for a change).
The other problem I only noticed after the upgrade was complete. The Xorg intel driver (for the chipset 865G) was painfully slow, manifestly obvious when dragging windows around the desktop. I tried various settings, gleaned from the internet, for example:
Option "AccelMethod" "exa" Option "MigrationHeuristic" "greedy"
but this made no difference. At some point, I noticed that the Xorg
log file stated that Shadow was enabled. This is bad according to
the intel driver man page:
Option "Shadow" "boolean"
This option controls the use of GPU acceleration and placement
of auxiliary buffers in memory. Enabling the Shadow will disable
all use of the GPU for RENDER acceleration and force software-
fallbacks for all but updating the scan-out buffer. Hardware
overlay is still supported so Xv will continue to playback
videos using the GPU, but GL will be forced to use software
rasterisation as well. This is a last resort measure for
systems with crippling bugs, such as early 8xx chipsets. It is
still hoped that we will find a workaround to enable as much
hardware acceleration on those architectures as is possible, but
until then, using a shadow buffer should maintain system
stability.
Default: Disabled
Hmm, well worth a punt. I ensured that Shadow was
disabled it in the xorg.conf file, via:
Option "Shadow" "false"
Fantastic, X speed now back to normal and no apparent instability.
Steel is a old Toshiba laptop, used as the second-line web and mail
server for hydrus. The only issue encounted during this upgrade was
during the install of sysv-rc, as noted above for gold.
However, there was an additional problem during the install of the latest CMUCL package. It gave the error:
Reinstalling for cmucl Recompiling Common Lisp Controller for cmucl Installing Common Lisp Controller in CMU CL ... Core uses SSE2, but CPU doesn't support SSE2. Exiting FAILED
This appears to be a problem in the Debian packaging and has been
reported (bug 526584).
Since that was opened nearly two years ago, I'm thinking it's not
going to be fixed any time soon. I downloaded CMUCL from the website instead.
Amber is my most modern machine, consisting of:
The motherboard included a Realtek ALC881 sound chip and a Realtek RTL8168c/8111c ethernet device.
During this upgrade, I noticed I didn't have the
linux-image-2.6-686 meta-package installed, so I installed
it prior to running the dist-upgrade. However, the kernel install
gave warnings about missing firmware for the RealTek RTL8168c/8111c
ethernet device. I manually installed firmware-linux-free,
but that didn't provide the necessary firmware. Nor did
firmware-linux-nonfree. What I needed was
firmware-realtek.
