Charles Curley - Software Engineer, Writer

(OK, "Linux on Lenovo" sounds better -- more alliterative. But I figured I should put the model in.)

I bought a Lenovo/IBM Thinkpad R51 (type 1836) in December, 2005, and it arrived with an infestation of Windows XP. These are my notes, intended to supplement other documents on the net.

More generally, there is a neat tool for checking hardware compatibility by running the results of lspci -n through a database: the Debian GNU/Linux device driver check page.

The Hardware

The sound, video, keyboard, rodent, USB, hard drive, CD-RW/DVD-ROM, and Ethernet all worked with no intervention. I have not tried the modem, and probably never will. I have not yet tried the cardbus controller.

The rodent is a bit unusual in that it has both a touchpad and a rubber stick input, and buttons to match. For more on that see this thread.

2006-07-23: The microphone is there and works, but pretty much useless. Get an external mic or headset.

Tools

Recovery CDs

Make a set of recovery CDs. From "Access IBM", follow the steps to make either a 7 CD set of recovery CDs or (if at all possible) a CD and a DVD. If you do the latter, put the CD in first, then the DVD. Then back up anything you want to preserve on the laptop's hard drive.

If your recovery partition has been damaged, you can restore it. Boot to the first recovery CD, the "IBM Rescue & Recover with Rapid Restore CD". Click on "Continue" in the flash screen, then on "Restore Factory Contents" to restore the Product Recovery Discs. Click "OK" and "No". Accept the terms and conditions, and click on "OK". Feed CDs as prompted. (More of the patience comes in here.) Reboot as requested. The system will take you to the Rescue and Recovery system.

Cohabitation: Adding Linux

I wanted to get Fedora Core 4 cohabiting with XP. I wrassled with that for a while. Lenovo ships the hard drive with two VFAT partitions. The second one (hda2) is the rescue partition. The first one is where XP will run. The first time you boot, XP will convert it to NTFS. I was skeptical about Linux' ability to resize an NTFS partition, so I tried resizing the VFAT partition to make some room. Wrong. The parted on Knoppix 4.02 clobbered both VFAT Windows partitions.

The solution: Let XP boot and convert the VFAT partition to NTFS. Then resize it. Mostly, I followed Cay Horstmann's instructions. One thing Herr Horstmann neglected to mention: install grub in the /boot partition before you grab its boot record to give to XP.

Having done that, I then hand built the partitions I would need with fdisk. Notice that I am not using Logical Volume Manager (LVM).

The three Linux (ext3fs) partitions became /boot, /, and /home, respectively. Running "sfdisk -d" on the results looks like this:

You might be able to take the first two entries out and feed that to sfdisk to reproduce my setup, but I haven't tried it.

Bare Metal Recovery Scripts

Earlier, I pretty well given up on having Linux and XP cohabit (due to inexpert googling). So I had installed Linux and left the broken Windows partitions alone. So while I mucked with this stuff, I used my Bare Metal Recovery scripts to preserve my Linux partitions. By judiciously commenting out certain stanzas in the restoration scripts, I was able to restore Linux and have it working almost flawlessly. N.B: the scripts are set to re-install GRUB to the master boot record. Change that! GRUB should restore to your /boot partition's boot record! I install GRUB to /dev/hda3.

IPW2200 Firmware

To use the wireless card, you need both the IPW2200 driver (included in the kernel) and the firmware. The firmware for the version of the driver that ships with Fedora 4 as updated (currently 2.6.14-1.1653_FC4) is 2.2, so you need ipw2200-fw-2.2.tgz. It works fine with my two Linksys WAP54G wireless access points, firmware version 2.08.

Unfortunately, it does not work as is with kismet, which requires firmware 2.3. Drat. (But see the note dated 2006-03-05 below.) If you insist, try this Fedora Core 2/3/4 and the IPW2200 Wireless Driver writeup from Clemson. I have not tried it.

I have found that you can have all the firmware versions you want in /lib/firmware/, so you might as well get them all and dump them in all at once. Check dmesg from time to time to see if a new kernel has called out a more recent version.

2006-02-12: the kernel-2.6.15-1.1831_FC4 has a version of the ipw 2200 driver that requires firmware version 2.4. I've gotten further: kismet now complains "FATAL: Failed to set monitor mode: Invalid argument." That will take some digging, who knows when.

2006-02-26: I probably won't go any further with this until FC5 is out and I get a chance to upgrade to it. Apparently, wpa-supplicant is a dependency for system-config-network, so perhaps kismet will work.

2006-03-01: Apparently, the firmware is available at Livna. Try yum install ipw2200-firmware. I haven't tried it.

2006-03-05: Hmmm, occasionally patience is a virtue. It turns out all I needed to do to get kismet working was wait for the 2.6.15-1.1833_FC4 kernel to come down the chute. When you run iwpriv eth1, you should see something like:

Kewl! Now to get a new GPS receiver (My old one being rather ancient, and not a USB receiver), get GpsDrive running, and start snooping the local networks. :-)

GRUB

2006-02-26: I had put an entry for the rescue partition in my grub.conf file. Alas, it does not work. I use the big blue "Access IBM" button instead. However, Andy Smout writes:

I bought an r50e laptop a few weeks ago and have read some of your article. I found some answers to some of the problems you experienced with grub.

Installing fedora core 4, after re-sizing the windows partition and setting a swap partition and ext3 or reiser partition for linux, I installed a basic fedora build with grub installed on the master boot record.

As you found, the ibm button no longer worked, and the ibm r&r partion also did not work. Grub appeared to screw up the partition table, and the type 12 compaq diag partition (ibm r&r) no longer worked properly. Although I could use grub to boot it, it would crash (blue screen). Without analysing the partition table in detail, it appeared to have a problem reading some sectors so I surmised the partiton type was wrong. Given the type of softwaed used in the ibm R&R partn (old windows on dos) the partition had to be a fat friedly type, and given the size of the data in the r&r partiion (approx 4gb) it had to be fat32, maybe lba type so I tried both. I discovered that changing the partition type to hidden w95 fat32 (LBA) [type 1c] fixed the ibm access r&r partition and those tools work fine after I fixed grub's menu.lst file. Partitions are as follows: hd0,0=win xp, hd0,1=ibm r&r, hd0,5=linux boot

Menu.lst:

Title winxp
Unhide (hd0,0)
Hide (hd0,1)
Rootnoverify (hd0,0)
Makeactive
Chainloader +1
Boot

Title ibm r&r
hide (hd0,0)
Unhide0 (hd0,1)
Rootnoverify (hd0,1)
Makeactive
Chainloader +1
Boot

Title fc4
Unhide (hd0,0)
hide0 (hd0,1)
Root (hd0,5)
Kernel /boot...etc etc

I tested this method by using the ibm recovery disk set to rebuild the whole pc to factory original, re-installed fedora using the same technique, and re-applied the partition table changes. This setup has been working fine for a few weeks now, and I have since re-sized (shrunk) the windows partion again and added a second linux (suse 10.0) install with additional entries in the grub menu for suse (suse re-writes/simplifies the grub config so I had to modify it again from a backup copy of the config files from pre suse to add back in the ibm, windows and fedora partition code listed above)

Hope that helps.

Note: I haven't tried Andy's code. Your mileage may vary, no warranty, use at your own risk, yada, yada.

Unless you take Andy's route, be sure to install GRUB to your /boot partition's boot record, not the master boot record! I install GRUB to /dev/hda3.

boot.ini

BOOT.INI is the file that tells XP what to boot. You can use it to present a choice to the user. One thing you can do is set the default to Linux. I named my boot record file dev.hda3.boot, so my BOOT.INI looks like so:

3D support for ATI Radeon

FC5: My testing of the Livna ATI drivers has been a disaster. The installation script (which you have to run manually) cannot tell the difference between the radeon and radeonfb modules, and (once I disabled the radeonfb) eats my configuration file, making it useless. This may be because the ATI driver does not support the 7500 cards.
Another reason to stick with the native drivers is that glxgears reports 1180 frames per second!

Suspend to RAM

I did exactly what Mr. Moss says to do. N.B: what appear to be two /usr/bin/dbus-send stanzas in sleep.sh are actually all one line. If you want to break them up to aid reading, use back slashes.

It appears my computer has the power drain problem described at thinkwiki. The fix on that page did not appear to work. The Clemson fix, which involves making a custom initrd (easy enough that even a congressman could do it), works.

2006-07-02: The 2.6.17-1.2139_FC5 kernel is causing problems with suspend. See bug 196835 for the gory details. I was able to work around it by changing one line, per Ed Hill's suggestion:

Updating Kernel Modules

2006-04-20: Two scripts which (their authors claim, I haven't tried them) will update these and more packages are Fedora Helper and Fedora Frog.

New kernels come out from time to time. I apply them assiduously. However, I now have two modules on this computer alone which are specific to each kernel and not in the kernel. Gnrrr. One can, of course, update them manually each time one updates the kernel. A bit easier is the following script. Since I just wrote it, you are on your own, use it at your own risk, there is no warranty, I'm not responsible for a dang thing anyway, etc., etc. It is copyright 2006, and released under the GPL.

This script also builds a custom radeonfb initrd, as the section above on suspending to RAM indicates.

For FC5, the Livna folks have seen fit to re-arrange the file names. I've re-worked the script. We no longer need the Radeon driver, so that went away. And the ntfs drivers get updated along with the kernel. That leaves only the frame buffer initrd to build.

Since these script have to be run while the new kernel is running, the first time you reboot after installing a new kernel the radeon frame buffer module is not installed. You could reboot. Easier to become root and install it manually.

Or add that line to the script, inside the if clause that makes the new initird.

2006-07-07: It appears that there is an undocumented config file for mkinitrd, /etc/sysconfig/mkinitrd. If it does not exist, create it, and add the line:

Once you've done that, when you install a new kernel, the radeonfb module will be included in the initrd. This removes the last excuse for this script, so it can go away. Thank you, Matthew Saltzman, for that information.

Update: Fresh Installation

On 23 July, 2006, I did a fresh installation of Fedora Core 5. First, I did a complete bare metal backup. I then cleaned out and reinstalled on the root and boot partitions, leaving all the rest intact. I did a minimal installation, figurng that a "yum install foo" would usually get me what I wanted.

Update: radeon_force_sleep argument to radeonfb

2006-10-22: It took me a while to track this one down, so I'll describe it here.

The Xorg driver for radeon has a problem with power management. The workaround is to install the radeonfb (frame buffer) driver even if you don't care about text mode.

So far so good. However, as of kernel 2.6.18-1.2200.fc5, the argument to the radeonfb driver "radeon_force_sleep=1" is no longer valid, and the driver refuses to load on discovering it. The solution is to change it to "force_sleep=1".

If you make this change, build yourself a new initrd to make it effective on boot.