I got a new Thinkpad T510 at work to replace my aging MacBook Pro. I asked for a Thinkpad instead of another MacBook because I wanted hardware with better hardware support, in particular the trackpad. I got into the habit of bringing a USB mouse everywhere I went because the trackpad on the MacBook was so unreliable on linux. So when my new T510 arrived, I was pretty excited. And, except for one tiny problem (of the PEBKAC kind), transferring all my files from the old machine to the new one went flawlessly. Here's how I set up the new machine:

• Download image from sysresccd.org. Follow the instructions to make a bootable USB drive.
• Boot up computer off USB drive. Resize the existing NTFS partition to be really small. Add 2 new partitions in the new-free space: one for the boot partition for linux, and one to be encrypted and be formatted with lvm.
• Format boot partition as ext3. Setup encrypted partition with 'cryptsetup luksFormat /dev/sda6; cryptsetup luksOpen /dev/sda6 crypt_sda6'. Setup LVM with 'pvcreate /dev/mapper/crypt_sda6'. Setup two volumes, one for swap, and one for the root partition.
• Connect network cable between old laptop and new one. Configure local network.
• Copy files from old /boot to new /boot.
• Copy files from old / to new /. Here's where I messed up. My command was: 'rsync -aPxX 192.168.2.1:/ /target/'.
• Install grub.
• Reboot!

At this point the machine came up ok, but wasn't prompting to decrypt my root drive, and so I had to do some manual steps to get the root drive to mount initially. Fixing up /etc/crypttab and the initramfs solved this. However even after this I was having some problems. I couldn't connect to wireless networks with Network Manager. I couldn't run gnome-power-manager. Files in /var/lib/mysql were owned by ntp! Then I realized that my initial rsync had copied over files preserving the user/group names, not the uid/gid values. And since I wasn't booting off a Debian image, the id/name mappings were quite different. Re-running rsync with '--numeric-ids' got all the ownerships fixed up. After the next reboot things were working flawlessly. Now after a few weeks of using it, I'm enjoying it a lot more than my MacBook Pro. It boots up faster. It connects to wireless networks faster. It suspends/unsuspends faster. It's got real, live, page-up/page-down keys! The trackpad actually works!

Thanks to vimperator, I've been liberated from non-vi keybindings in firefox! In Debian, it's just a quick apt-get install iceweasel-vimperator away!

I don't get lolcats. or lotcatz. whatever. People keep sending me links to them. People keeping making them. They show up in my RSS feeds with frightening frequency. I have to admit, however, that these were pretty funny: http://blog.rominet.net/2008/05/debianopenssl-debacle.html. Mmmm...antropi.... Also, did you know that apparently there can be improper lolcat grammar!?

Man, I wish I had known about this before! nmudiff is a program to email an NMU diff to the Debian Bug Tracking System. I often make quick little changes to debian packages to fix bugs or typos, and it's always been a bit of a pain to generate a patch to send to the maintainer. nmudiff uses debdiff (another very useful command I just learned about) to generate the patch, and email it to the bug tracking system with the appropriate tags.

I previously posted that I had problems getting my wireless device working with the new 2.6.24 kernel, running into a kernel oops in the process. In kernels prior to 2.6.24 I used the bcm43xx driver, and let NetworkManager handle connecting to wireless networks. I've since had some time to play around with 2.6.24 a bit more, and I'm happy to say wireless is working now! Here's what I did: - Install b43-fwcutter - Add b43 to /etc/modules - Add ', ATTR{type}="1"' after the MAC address to the line in /etc/udev/rules.d/z25_persistent-net.rules that contains your wireless device. This ensures that udev will assign the same interface name to the wireless device as it had before, which means you don't have to reconfigure your firewall!

The linux-kbuild-2.6.24 package was finally available in Debian today. (Small aside: why does it always take a few days after the release of the linux-image packages before the linux-kbuild package is available?) I need to use the proprietary nvidia drivers on my machines, so I have to wait for the kbuild backage before I can compile and install the nvidia driver for the new kernel. Anyway...after a short 'sudo m-a a-i -l 2.6.24-1-amd64 nvidia', I could reboot into the shiny new kernel! New kernels always seem faster, so I was getting excited after booting up. After logging in though, I couldn't connect to my wireless network. I had previously been using the bcm43xx driver, and looking through the changelog, I discovered it had been deprecated in favor of the new b43 / b43legacy drivers. Ok, no problem, just load the new module...wait for network-manager to pick it up...wait for it...wait...wait...Screw it. Edit /etc/network/interfaces, uncomment the stuff for the wireless device, and then 'ifup eth2'. Kernel oops. Well that sucks. Back to 2.6.23 I go. Incidentally, it's not just this oops in 2.6.24 that has me disappointed. Everything since 2.6.18 has been a bit risky. It used to be that upgrading a kernel within the same major.minor release was a relatively safe thing to do. I actively use two different kernels on my machine at home: - 2.6.21 since it supports the raw1394 interface that dvgrab requires to download video from my camcorder, but wireless is very flaky - 2.6.23 since wireless is more robust I still occasionally get lockups, forcing a hard reboot. Maybe this is my fault, I am running the proprietary nvidia driver, and I do use suspend to ram quite a bit, even though it thinks my hardware isn't supported. Maybe too much is changing too fast between kernel releases, not allowing userspace to keep up? Not sure, all I know is I'm doing much more rebooting in my Linux machine than I used to.

Somehow when reading through the Linux 2.6.17 changelog last week I came across a few articles discussing the kexec feature of recent Linux kernels. It's pretty neat, you can boot directly into another kernel image without having to go through a hardware / BIOS reboot. There's a Debian package called kexec-tools which gives you the ability to load these kernel images into memory and to boot into them. I found kexec a bit cumbersome to use, especially since all the kernels I care about booting into are the stock Debian kernels, and they all ship with ramdisk images that need to be used properly to boot. Using kexec by itself also requires that you have to manually bring the machine into a rebootable state first, or hack up some system scripts. You shouldn't just boot into a new kernel directly without shutting down devices, unmounting file systems, etc. So to scratch this itch, I wrote kexec-chooser. It's a small Python script that will allow you to easily warm-reboot into any of the stock Debian kernels installed on your system. It'll probably work with custom kernels as well, but I haven't tested that yet :) Downloads and more information can be found on the kexec-chooser page.

vim7 is now available in debian unstable! And there was much rejoicing.

Ok, well maybe a bit of an exaggeration, but partly true :) Linus Torvalds has just been accepted as a Debian Developer, which means that, "Debian will have the advantage of being the distribution with the most official Linux kernel." World domination is one step closer....muahahahahahaaaaaaa... (seen on Planet Debian)

At least that's the way it feels! I just realized that my laptop supports 1600x1200 resolution! And I've been running it at 1024x768 all this time! So after fighting with the fglrx drivers for Debian, I can finally surf the web and read e-mails without having to scroll left and right all the time! Setting up fglrx was less than painless to put it mildly. For future reference, I had to do something like this:

aptitude install fglrx-kernel-src

cd /usr/src

tar jxf fglrx.tar.bz2

cd modules/fglrx

export KVERS=2.6.16-1-686

export KSRC=/usr/src/linux-headers-${KVERS}

debian/rules binary_modules

I would have hoped that m-a a-i fglrx would have worked, but alas... Oh, and other thing. ATI: it isn't cool to lock up the machine just because your driver doesn't support 16 bit colour. I had set my default colour depth to 16bpp previously in an effort to get higher resolution with the radeon driver, but when I started using the fglrx driver things would just lock up.