On Friday my new Lenovo ThinkPad x220 arrived and of course in the evening after I finished work, I was jonesing to put Fedora 15 on it. The machine is a type 4286CTO (Smolt info here). I started by booting into the BIOS and checking the options as shipped by Lenovo. There wasn’t much to change here, other than to enable hardware virtualization so I could more easily run KVM on the laptop should I choose to do so later. I didn’t enable the extra direct IO option, VT-d, because I’ve seen it cause weird installation problems in a lot of cases.
While I was starting to work on my new laptop, I also took the time to refresh my backup of data on the laptop I’ve been using, a ThinkPad x201 graciously lent to me by Tim Burke when my Dell XPS M1330 started to go belly-up a couple months ago. I used rsync to sync everything to a large USB drive.
Then I grabbed a spare 64-bit Fedora 15 Live USB key with the standard Desktop image and booted from it, just to see what I might expect from an installed system. I was impressed (but not really surprised) to see that everything worked great out of the box (with one trivial exception I’ll cover below). Not only the standard stuff like video hardware acceleration, special keyboard buttons, Bluetooth, sound, and suspend/resume, but also stuff like the webcam (at full resolution) and wireless. So I tried an installation from the Live key, and everything went fine — and fast, due to the new 2nd-generation “Sandy Bridge” Core i7 processor on this notebook.
Booting that went flawlessly, so I decided to try a more full-featured install over the network. I copied the pxelinux images for the kernel (vmlinuz) and initial ramdisk (initrd.img) to the /boot folder, edited the /boot/grub/grub.conf file to add a boot stanza, set the new boot stanza to be the default, and then restarted. Spoiler: this installation also went flawlessly. When it came time to deal with the package configuration, I did two things:
- Using the installer’s ability to edit repository configuration as part of the interactive installation, I pointed the installation at my home network, for speed purposes — having made sure my local mirror of content was updated with the latest content already.
- I made sure the “Updates” repository was turned on (and also pointed at local content). This would save me having to do a separate update after installation.
In minutes I had a working system. Using some of the yum-fu from an earlier post, I added in missing packages that were on my previous system.
Now came time to restore my user data. However, I decided to forego using the USB drive for restoration, because here I was with two relatively speedy laptops, each equipped with a gigabit Ethernet network interface. Nowadays these interfaces don’t need special loopback or null cables; they can autosense direct connections and adjust accordingly. So I cabled the notebooks together and used the easy NetworkManager tool to set up the wired interfaces with manual addresses on the same IPv4 network.
A quick check with ping showed I was ready to go, so I ran rsync over SSH to pull all the user data (in /home) from one box to another. This step probably saved me about half the time that the USB copy would have cost thanks to greater bandwidth over gigabit Ethernet versus USB 2.0. (The new laptop has USB 3.0 but the backup drive I have is USB 2.0.)
One of these days I’ll get around to puppetizing my home network, but I just don’t have the time for it these days. So my last step was manually grabbing an assortment of configuration info from my old laptop:
- Stuff from /etc/NetworkManager/dispatcher.d/ and /etc/postfix/ to support my laptop email solution (start here if you want to learn more about it)
- Some web server configuration files from /etc/httpd/conf.d/ so I can run my local sandboxes of Drupal
- A little more info from /etc/NetworkManager/system-connections/ where I have some system-wide connection profiles
And with that, I was ready to go. Actual “me time” expended on all this was less than an hour, if you count both installations, post-configuration tasks, and miscellaneous piddling around in the middle. Of course I wandered off and did other things while the data copying was going on, so I’m not counting that time.
As I mentioned, everything worked perfectly on the installed system with one tiny exception. Even the fingerprint scanner was set up in a matter of seconds, using the handy GNOME 3 “My Account” tool. Interestingly, if you’re one of the poor unfortunate unwashed using Windows 7 (even the so-called “Ultimate” edition), both the webcam and the fingerprint scanner have to have extra drivers installed if you want to use them. But in Fedora? Nope. It all works 100% out of the box. What’s the exception then? The only thing that’s not functioning yet is the new “microphone mute” function button. The button does issue a key press signal, but it’s not captured by anything yet. This is also an “extra driver needed” for Windows users, but true to form, the new button is already on its way to working out of the box in Linux, thanks to the awesome work of community members. My bet is you’ll see this enabled in a kernel update in Fedora 15, or at worst in Fedora 16 which will be out in a few months.
Hopefully this will be helpful to anyone who’s considering one of these fine laptops. ThinkPads are kind of the Cadillac of laptops for IT worker bees, in my opinion. Or maybe I mean Toyota truck? Anyway, they’re tough, reliable, full-featured and in the case of the X series, highly portable. And they work absolutely great with Fedora and Linux in general. Happy hacking!