Another job, another laptop. This time I have a Lenovo Thinkpad Z61p, a weighty beast. Given the amount of memory and horsepower available, I thought I'd use VMWare under Windows XP to run UNIX (FreeBSD and Debian). While this worked very well, I couldn't shake myself out of feeling there was something fake about this implementation. I therefore decided to install either Debian or FreeBSD on the naked hardware.
After some investigation, I decided on Debian, due to the better support for the wireless card (Intel 3945ABG). FreeBSD has a driver in the works, so I may switch when/if it hits the STABLE code stream.
First, I used gparted to free up 10GB of the Windows XP NTFS partition. Even though I had created copies of the Restore/Repair partition onto CD and DVD, had backed up all my files, I still rebooted into Windows with some trepidation. As described in the gparted help, Windows performed a CHKDSK operation on the newly partitioned disk (with no errors) and then rebooted. I started to get a little worried after I logged in and the desktop had not appeared for two minutes... But then it appeared and everything seemed to be as before. I rebooted again, to see if the delay was some effect of the CHKDSK. Hmm, same delay, so there must be some other cause. Since the only difference was the hard disk now had 10GB of free space, I created a new partition and formatted it as NTFS (but did not assign a drive letter). Ah ha, login after reboot was back to normal. I wondered if this issue would re-emerge after installing Debian... oh well, only one way to find out. [It did.]
I booted from the first CD of the Debian Etch install set (the only one I've bothered with). I partitioned the 10GB I had to play with as follows:
/ 250MB /usr 3750MB /home 3750MB swap 950MB /var 950MB /tmp 400MB
Installation went fine, until I tried to install Grub. I wanted to
retain the Windows boot manager, so didn't install Grub on the MBR,
but attempted to install Grub on the first Linux partition.
However, I forgot that the disk was seen as SCSI and should have
been identified as /dev/sda5. Wrongly, I used
/dev/hda5. This caused an error, naturally. However,
after that I couldn't get Grub to install, even with the right
device identification. In the end I had to go back to the
partitioner, reformat the partitions (I just re-used my settings
from before) and re-install the software.
Now, to use the Windows boot manager to boot Etch, I had to take of
copy of the first 512 bytes of /dev/sda5 and transfer this
copy to the Windows XP drive. There seemed to be no way to do this
from the alternate Debian console. I therefore downloaded a copy of
Super Grub,
available in a handy ISO, with which I could boot Grub and then boot
the new Etch instance. Using a dd command like so:
dd if=/dev/sda5 of=/mnt/linux.bin bs=512 count=1
I copied the first sector to a USB stick (mounted on /mnt.
With the linux.binfile copied to C:\ of the
Windows partition, I edited C:\boot.ini so that it looked
as follows:
[boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /noexecute=optin /fastdetect c:\linux.bin="Debian Etch"
Debian Etch now shows as a boot option. When selected, it
throws up the Grub boot menu on /dev/sda5 and I can boot
into Etch.
As described in a few articles on the web for Thinkpads using
similar hardware, for example here
(20100123: link updated as etch install discussion has been removed) and there,
the drivers for the Intel 3945ABG are available via
apt-get. Ensure that you have contrib and
non-free specified in your /etc/apt/sources.list
file, e.g:
deb http://ftp.debian.org/debian/ etch main contrib non-free
First, I upgraded the Etch installation to the latest package revisions by:
apt-get update apt-get dist-upgrade
Then, I installed the required packages for the 3945ABG card:
apt-get install firmware-ipw3945 ipw3945d ipw3945-modules-`uname -r`
This complained that the package
ipw3945-modules-2.6.18-4-686 could not be downloaded. Ah,
that's probably because the latest version is 2.6.18-5-686 (and I
hadn't rebooted to get the new kernel up after the
dist-upgrade.
Once these packages were installed, I also installed
wireless-tools and then configured
/etc/network/interfaces as follows:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo eth2
iface lo inet loopback
# Broadcom wired lan (usually unused)
iface eth1 dhcp
# The primary network interface
allow-hotplug eth2
iface eth2 inet dhcp
# wireless-* options are implemented by the wireless-tools package
wireless-mode managed
wireless-essid MYAP
wireless-key1 deadbeef00
I rebooted, and while the wireless card was recognised, it did not
want to associate with my wireless access point (MYAP). I tried a
few things, but it remained stubbornly at Unassociated. It
wasn't until I tried iwlist eth2 scan that the wireless
card associated with MYAP and the laptop was given an IP address.
There appears to be some problems with this driver; I'm getting a high level of packet loss, sometimes as high as 20%. This manifests itself as slow DNS lookups.
The Z61p has an ATI Mobility FireGL V5200 graphics adapter. When I
installed xorg, it was configured as VESA, which
seemed to work fine until I killed X to return to the console.
There, I found the console text size had somehow tripled.
The fix for this was to add vga=794 to the grub kernel
command line i.e.:
title Debian GNU/Linux, kernel 2.6.18-5-686 root (hd0,4) kernel /boot/vmlinuz-2.6.18-5-686 root=/dev/sda5 ro vga=794 initrd /boot/initrd.img-2.6.18-5-686 savedefault
The vga setting of 794 puts the console into a 16bit 1280x1024 text mode.
The bigger problem with VESA was that it did not support the full screen resolution (1920x1200), but only 1600x1200, which also had the undesirable side-effect of stretching the display horizontally. This meant it was necessary to install the fglrx driver, as shown below.
Note: for the m-a commands to work, you need to have
the package module-assistant installed.
apt-get install fglrx-control fglrx-driver fglrx-kernel-src m-a prepare m-a a-i fglrx #build the module # set up the xorg.conf file. aticonfig --initial --input=/etc/X11/xorg.conf
The Video Device section in the xorg.conf file should now look like this:
Section "Device"
Identifier "aticonfig-Device[0]"
Driver "fglrx"
EndSection
The fglrx driver supports the full resolution. I haven't noticed any problems in using it so far.
Now that Debian was installed and basically working, I returned to Windows to make sure everything still worked. As I feared, the mysterious slow boot had returned. So, my next task was to figure out why Windows XP was booting so slowly. The symptom was that following login, it took about 90 seconds for the desktop to appear. During much of this 90 seconds, nothing was happening; no disk activity, no CPU. Following various bits of advice from the Internet didn't help much. I tried:
C:\Windows\Prefetch. No change.
TpShocks and TPHKMGR from the Startup
sequence (using msconfig). Ah ha! Back to normal.
Now things get a little weird. To find out which of the two,
TpShocks (Thinkpad Drive Shock Detector) or
TPHKMGR (Thinkpad HotKey Manager) was the culprit, I
re-enabled TpShocks (which was my prime suspect). The
startup speed remained unchanged i.e. still fast. I couldn't
believe TPHKMGR was to blame and, sure enough, when I
re-enabled it, the startup speed was still OK.
My working theory is that the key act was the deletion of the
contents of C:\Windows\Prefetch. Perhaps the effect was
hidden by the need to re-fetch everything on the first reboot. If I
had re-booted twice, perhaps it would have been obvious that was the
key fix. I must remember to investigate further, if there is a next
time.
At boot (and shutdown) time, accesses to the clock cause an
error of the form select() to /dev/rtc to wait for clock
tick timed out. It is a known problem (bug 7014), but
since bugzilla.kernel.org is down, I can't direct you to the
original bug report. The bug can be worked around by adding the
following line to /etc/default/rcS:
HWCLOCKPARS="--directisa"
A couple of times, Etch has hung during the boot process, always on probing the CD drive. Resetting and rebooting has so far worked. More investigation needed.
