Ryan's Scraps

A group of changes have recently been committed to edge Rails that allows the use of the various REST style HTTP methods when creating links. Deprecated are the days of using :post => true to indicate a data-altering request (post being only one of the five main REST methods):

Bye-bye this:

link_to("Delete article", { :action => "destroy", :id => @article },
  :confirm => "Are you sure you want to delete this article?",
  :post => true

And hello to proper REST (note the * :method => :delete* and * :method => :put*)!

link_to("Delete article", { :action => "destroy", :id => @article },
  :confirm => "Are you sure you want to delete this article?",
  :method => :delete)
link_to("Edit article", { :action => "edit", :id => @article },
  :method => :put)

All your favorite helper methods now support REST verbs including link_to, link_to_remote, form_tag, form_for, remote_form_tag and remote_form_for.

Now you can start building links with verbs that actually represent the type of request being made. On the controller side you can determine the request method the same way you always have – with the request.post?, request.get?, request.put?, request.delete?, request.head? methods.

On a related note, here are some links to work being done on providing REST-ful controllers for rails:

• http://cfis.savagexi.com/articles/2006/03/26/rest-controller-for-rails
• http://microformats.org/discuss/mail/microformats-rest/2006-March/000158.html
• http://pezra.barelyenough.org/blog/2006/01/rough-resting-on-rails/
• http://www.xml.com/pub/a/2005/11/02/rest-on-rails.html?page=1

tags: REST, rubyonrails, rails

Rails does many things well, but one of the best is providing a framework for easy and complete testing. However, continuous integration, theoretically a by-product of easy testability, doesn’t seem to be a major player in the Rails landscape yet. One good reason is that there’s not yet a continuous integration application like CruiseControl or AntHill out for ruby. Sure, there have been sightings of such tools like CIA (seems to have been deprecated) and Damage Control, and there is the handy Autotest which kind of gives you a continuous integration feel – but what about real continuous integration?

Well, we do have an option in the form of the continuous_builder plugin. Is it a slick web-app that lets you configure your build process within the comforts of a GUI? No. But, it does automatically run all your tests on every subversion commit and send a nasty-gram calling out the person who broke it, and that’s pretty much what continuous integration is right?

On a side note, I would love to see an open-source CruiseControl for Rails developed and suspect one will be out shortly as the community grows even further

So how does one get the continuous builder plugin up and running? Read on…

Install continuous_builder Plugin

Installing the continuous_builder plugin is a cinch since it’s part of the rails source tree and is a recognized plugin repository.

cd app
script/plugin install continuous_builder

You can also manually install it if the plugin install doesn’t work for you – though I don’t know why it wouldn’t.

cd app
cd vendor/plugins
svn export http://dev.rubyonrails.com/svn/rails/plugins/continuous_builder

Configure Environment & Mailer

The builder plugin runs as a rake task triggered by subversion’s post-commit trigger. However, it needs a few things before it can just work.

The first thing to note about the plugin is that it’s a bit of a dichotomy. When it runs the rake task to perform the tests (all unit, functional and integration tests) it runs under the test environment. That part is easy and expected. However, what you should also know is that the builder runs inside the development environment by default (which is normal for all other rails commands but slightly unintuitive in this particular situation). This means that, if left as is, the builder will pull the action mailer config from the config/environments/development.rb configuration (or config/environment.rb if there’s one configuration for all environments). So to summarize, the builder configuration wil pull from the development environment config and the rake testing task operates in the test environment.

This could be an issue if your development config doesn’t send real emails (your test config probably wouldn’t either since you’d usually be using ActionMailer’s mock delivery to unit test email functionality). What I would suggest doing to keep your builder configuration seperate from your other environments is to create a new build environment config file. This involves

1. Creating an config/environments/build.rb config file with a working ActionMailer config
2. Updating config/database.yml to point to a build database (this can be an empty db as all it will do is create an initial connection (though I wouldn’t suggest pointing to the test or production db)

Now we can safely tell the builder to use the “build” environment to get its mailer configuration, and we can leave the other environments untouched.

Test Configuration

Once you have your build configuration setup (or even if you haven’t chosen to do that), you’re going to want to test the builder. This can be done on your local machine, though it requires some little hacks to make the mail function trigger.

The mail functionality will trigger when the build or tests fail and there’s code to update from the repository. To simulate this I created a unit test that always failed, and reverted one small portion of the code to a previous version (using svn update -r _previous revision#_ ). Once you’ve got this simulated failure setup, run the following:

# Omit "RAILS_ENV=build" if you did not set up a seperate environment
# Include the BIN_PATH if your rake executable is not located
# at /usr/local/bin (and include the trailing "/"!)
RAILS_ENV=build BIN_PATH=/usr/bin/ rake -t test_latest_revision \
NAME=app_name RECIPIENTS="dev-list@yourcompany.com" \
SENDER="build@yourcompany.com" 

If all is setup correctly, you will see the standard test output and should see the build status output to the log/last_build.log file. If anything is wrong it should be recognizeable as a build or test error. Fix it and try again :) (and don’t forget to re-setup the fake failure situation described before)

Setup Environment on Build Server

Now that you know your plugin is working, you have to duplicate that setup on the build server – which has to be the same server that subversion is running. Here’s the process I went through:

1. SSH to the subversion machine as the user that subversion runs as
2. Make a directory where the builder can check out your source to (I’ve used /tmp/rails/app)
3. Checkout the code to that directory from the command line – just to make sure you can
4. Edit the hooks/post-commit file located in your subversion repository directory to look like this (for me this was ~svn/repo/hooks/post-commit)

#!/bin/sh

# Set vars (if necessary)
BUILD_DIR=/tmp/rails/app
BIN_PATH=/usr/bin

# Execute builder (use the same command that worked on your local
machine in the previous test scenario)
cd $BUILD_DIR && \

# Make sure we have the latest and greatest db structure
$BIN_PATH/rake migrate VERSION=0 && \
$BIN_PATH/rake migrate && \

# Run continuous build task!
RAILS_ENV=build BIN_PATH=$BIN_PATH $BIN_PATH/rake -t test_latest_revision \
NAME="App" \
RECIPIENTS="dev-list@yourcompany.com" \
SENDER="build@yourcompany.com" 

Once the post-commit file is in place, you need to do make sure of a few things:

1. That your post-commit file is owned by the user that the subversion process runs as
2. That your post-commit file is executable by that user
3. That the subversion user can checkout code to the build directory (easy as setting that user to be the owner of the build dir)

An easy way to test this setup is to run the post-commit file from the command line. Since it’s executable you should be able to just run ./post-commit. If you’ve recreated the fake failure scenario on the build server as you did on your local machine you should get the nasty-gram email sent to the dev-list@yourcompany.com email address. If not you should at least see the process output.

Test in Production

Now the only thing left to do is to test the builder on an actual commit. This is pretty easy, all you have to do is commit a test that fails. You should see an email pop up in your inbox saying that you wreaked havoc on the build, bringing the scorn of the developers upon you.

Damn – that was a lot. Hopefully you’re now living in continuous build nirvana…

Resources:

http://dev.rubyonrails.org/browser/plugins/continuous_builder

CIA Stuff:

http://wiki.rubyonrails.org/rails/pages/How+To+Use+CIA+For+Continuous+Integration http://article.gmane.org/gmane.comp.lang.ruby.rails.core/790 http://blog.innerewut.de/articles/2005/09/18/setting-up-cia-with-rails-and-subversion

tags: rubyonrails, continuous integration, agile

I like to keep a close eye on the changes being committed to edge Rails as it’s a great learning experience – and thought I might as well post a summary of them as they roll in. This will definitely not be an exhaustive effort – just something as I see fit or have the time. So here goes the first one:

Rails Changeset 4365; Add generator files…

This changeset simply adds the files necessary to use the script/generator utility to auto-create observer stubs. What’s an observer you ask? It’s a way to monitor lifecycle events of a model object outside of the model itself and let’s you avoid cluttering the model class with logic that’s not core to the model.

So how does one use this new observer generator? Observe:

ruby script/generate observer User

Yeah, that’s really it. This will create two files for you, the observer class itself at app/models/user_observer.rb:

class UserObserver < ActiveRecord::Observer
end

and the unit test at test/unit/user_observer_test.rb:

require File.dirname(__FILE__) + '/../test_helper'

class UserObserverTest < Test::Unit::TestCase
  fixtures :users

  # Replace this with your real tests.
  def test_truth
    assert true
  end
end

You can then edit the observer class with the appropriate callback methods:

class UserObserver < ActiveRecord::Observer
  def after_save(comment)
    # Do something great
  end
end

On a side note, I feel like the generator utility has been getting a bad rap recently from people that frown upon auto-generation of code. Fair enough, but think of them more as best practices templates and learning tools rather than some sort of coding robot. They’re really great tools for seeing how things should be done, and how things are expected to be done. If you don’t want to use them, don’t – but if you’re not quite sure how to go about creating an observer, or controller, or model they’re of great help.

So there you have it – the new observer generator functionality in edge Rails.

tags: rubyonrails, generators

Otherwise known as “Testing Rails Controllers with Complex Parameter Types”

A co-worker of mine and I ran into a Ruby on Rails controller testing issue recently that stumped us for quite awhile. In hindsight, it shouldn’t have.

Here is our story.

Said co-worker is new to Rails and was working through his first functional test – in this case a pretty standard login controller test. He was testing the account creation (add_user) action like this:

def test_create_account
  # Emulate account creation request
  post :add_user, { :username => 'user', :password => 'pass' }

  # Test that successful creation redirects to login
  assert_redirect_to :controller => 'login', :action => 'login'
end

Easy enough, yeah? Well yes, except this doesn’t work. I quickly figured out that it was because the controller method was looking for parameters in standard rails format as a hash of the “user” key in the param hash:

def add_user
  @user = User.new(params[:user])   #Note the "params[:user]" 
  if request.post? and @user.save
    redirect_to(:action => "login")
  end
end

Arguments were being passed in as their simple property names like username but the controller was looking for that property on the collection parameters for the user, hence the params[:user]. Okay, easy enough, we just need to pass in these nested types in our functional test.

Unfortunately, the documentation we were aware of (here and here) always use very simple examples without nested parameters.

So, after going through all of these formats modeled after what the parameters are called in the actual view:

• :user_username = ‘user’
• ‘user_username’ = ‘user’
• ‘user[username]’ = ‘user’

I finally admitted defeat and took a peek at some of Typo’s functional tests to figure out what is quite intuitive in hindsight. Because you’re passing in a mock representation of the real HTTP parameters, you don’t want to use the string versions of the parameters but actually set the parameter hash directly. Duh.

So, when your controller is expecting a nested hash keyed off the :user symbol, give it one!

def test_create_account
  # Emulate account creation request
  post :add_user, { :user =>
                    {:username => 'user', :password => 'pass' }
                  }

  # Test that successful creation redirects to login
  assert_redirect_to :controller => 'login', :action => 'login'
end

Thank you open-source, and Typo specifically.

tags: rubyonrails, functional testing

Here’s a quick howto on a process that doesn’t seem to be very well supported or documented: Getting your contacts and addresses out of Novell Evolution and into Mozilla Thunderbird (or any other similar mail client like Yahoo Mail etc…)

Exporting from Evolution is not something that’s very apparent. Unless you want to export your contacts as a VCard (by highlighting all and doing a save as vcard) you’re going to have to call upon the obscure evolution-addressbook-export command. For some reason this utility wasn’t in my path, so I had to call it directly.

On Debian Sarge, the basic sequence goes like this:

1. Export the evolution address book with the evolution-addressbook-export utility in csv format
2. Import it into Mozilla Thunderbird
3. Export as needed in other formats to other mail clients (LDIF seems to work well for Yahoo! Mail…)

It’s really simple once you know what to use and where to find it:

/usr/lib/evolution/2.X/evolution-addressbook-export --format=csv > contacts.csv

Now just import it into Mozilla Thunderbird (Addressbook – Tools – Import).

I don’t know why it’s hard to find references to Evolution’s addressbook export utility – it seems to address a pretty big need. Hope this helps somebody…

tags: evolution, debian, thunderbird

Installing Debian Sarge on a Dell Latitude D610 is a little hairier than it should be. I’ve installed deb on both a d500 and a d610 and the 610 is quite the little bugger. Why? Serial ATA (SATA).

Debian Sarge (3.1) includes v2.6.8 of the kernel which doesn’t have serial ata support built in, but the Latitude D610 has sata drives. When that kernel loads on this laptop it can’t find any drives, and apparently those are needed to properly operate your machine.

There are a few other sites that do a great job of showing you how to get over this hurdle, but most involve using testing or unstable packages – something I explicitly want to avoid – or reference debian kernel-source packages that I can’t seem to find (see resources at the bottom for those other sites). I want this to be an all-stable installation of deb that I can refer to in the future independent of the kernel source already made available as a package. The solution is somewhat simple, but does involve compiling your own kernel plus some other nuances that are easy to get hung up on. Let’s see what it’s going to take to get Deb up and running on a D610…

1. Installation
2. Upgrade Kernel
3. Wireless
4. Hibernate/Software Suspend

Installation

Because of the aforementioned SATA incompatability, you’re going to need to initially install the 2.4 version of the kernel.

1. Get a copy of the debian sarge installation CD (I like to use the net install)
2. Make sure your laptop is plugged into a working ethernet jack (the internal wireless card won’t work during installation)
3. Boot up with expert or linux at the boot prompt, whatever you’re comfortable with (just avoid expert26 or linux26)
4. Go through a normal installation except when it asks you what version of the kernel to install – choose the 2.4.x version.
5. When it asks you what packages to pull from apt – choose the “Stable” option
6. Reboot into your 2.4 kernel. If you can’t get to this point, then we’ve got issues. If so, comment below and I’ll see if I’ve run across your issue.

Kernel Upgrade

Now that we’re comfortably sitting in our new 2.4 kernel, we need to compile our own 2.6 kernel with SATA support. If you want to skip all the details and are on a latitude d610, then you may be able to use my kernel packages. If you want to give it a try, download these two files and then skip to the step below where it says ‘dpkg -i kernel2.6.12.deb’

kernel image

kernel headers

If you’re not into using my kernel packages, then proceed from the first step here:

# Install the necessary kernel compilation packages:
apt-get install module-init-tools kernel-package libncurses5-dev fakeroot wget bzip2

# Change into the /usr/src directory
cd /usr/src

# Download the vanilla kernel source - I've had the most success with the 2.6.12 version...
wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.12.6.tar.bz2

# Download my kernel config file (probably a good base for any setup but should only be used confidently on Dell Latitude D610)
wget http://ryandaigle.com/files/linux/config-2.6.12.6

# Unpack the kernel source
tar xjf linux-2.6.12.6.tar.bz2

# Change into the source dir
cd linux-2.6.12.6

# Copy the kernel config to the source dir (as .config)
cp ../config-2.6.12.6 .config

# Make the kernel and headers image deb packages (this will take some time and should complete with no errors)
make-kpkg clean
fakeroot make-kpkg --initrd --revision=custom.1.0 kernel_image kernel_headers

# At this point you should have two .deb files in /usr/src that can be used to install
# the kernel image and its headers (kernel-image-2.6.12.6_custom.1.0_i386.deb
# and kernel-headers-2.6.12.6_custom.1.0_i386.deb)
cd ..
dpkg -i kernel*2.6.12*.deb

# Now we have to change the references in /etc/fstab and /boot/grub/menu.lst from
# hda to sda.
#
# Where it has
# kernel          /vmlinuz-2.6.12.6 root=/dev/hdaX ro
#
# Change to
# kernel          /vmlinuz-2.6.12.6 root=/dev/sdaX ro
nano -w /boot/grub/menu.lst

# And do the same for /etc/fstab.
# Every reference to hdaX, change to sdaX
nano -w /etc/fstab

At this point you should be able to successfully reboot into your new v2.6.12.6 kernel. I’ve done this several times so I don’t doubt that I’m taking some step for granted. If you’ve found I missed a step or something needs some clarification, definitely let me know.

Wireless

If you’re at this step then chances are you’re running a 2.6 kernel but are still tethered to your ethernet chord. Unacceptable! Let’s get rollin’ with wireless.

The Latitude D610 uses the Intel PRO/Wireless 2200BG chipset, which has pretty good driver support thanks to an open source project Intel created for the purpose (as well as the ieee80211 project). Getting this network interface up is a matter of downloading some source and compiling, which has usually gone off without a hitch. These steps below were mainly derived at after reading over this official howto. Don’t be intimidated, just take my lead…

# Install the wireless tools package
apt-get install wireless-tools

# Change back into our trusty /usr/src dir
cd /usr/src

# Download the stable versions of the required source (both ieee80211 and ipw2200 source files)
wget http://umn.dl.sourceforge.net/sourceforge/ipw2200/ipw2200-1.1.0.tgz
wget http://umn.dl.sourceforge.net/sourceforge/ieee80211/ieee80211-1.1.13.tgz

# Download the latest ipw firmware.  Normally you would have have to do this via a
# browser since they don't allow direct downloads, but here is the bundle I used
# (since text-based browsers like lynx didn't want to download it from their
# sourceforge page: http://ipw2200.sourceforge.net/firmware.php?i_agree_to_the_license=yes&f=ipw2200-fw-2.4.tgz)
wget http://ryandaigle.com/files/linux/ipw2200-fw-2.4.tgz

# Unpack, compile and install the ipw2200 and ieee80211 source
tar xvzf ipw2200-1.1.0.tgz
tar xvzf ieee80211-1.1.13.tgz
cd ieee80211-1.1.13/
make
make install
cd ../ipw2200-1.1.0/
make
make install

# Unpack and install the ipw2200 firmware
cd /usr/src
mkdir ipw2200-fw
mv ipw2200-fw-2.4.tgz ipw2200-fw/
cd ipw2200-fw/
tar -xvzf ipw2200-fw-2.4.tgz
cp *.fw /usr/lib/hotplug/firmware

# Now load the modules
modprobe ieee80211
modprobe ipw2200

# Make sure you see the proper device recognition in dmesg..
dmesg

At this point you should now be able to configure your wireless settings to connect to your AP. These are the commands I use to connect to mine (I have this in a script so I can reuse it when I roam to other APs)

# Take down our landline
ifconfig eth0 down

# Configure wireless card for WEP encrypted AP
iwconfig eth1 essid "MYSSID" mode Managed key restricted MY_HEX_KEY

# Or if we have an un-encrypted AP
# iwconfig eth1 essid "MYSSID" mode Managed key off

# Get our IP (assumes DHCP)
dhclient eth1

Now, ping google or run ifconfig to see your new wireless device. There you have it, a working wireless connection, how sweet it is. If it’s not so sweet, let me know what problems you run into…

Suspend/Hibernate

In the past I’ve installed software suspend 2 on my personal Dell Latitude D500 to get hibernation working, but now need to get it up and running on my work Latitude D610. I went through most of the steps trying to get software suspend 2 to work on the d610, but in the end I couldn’t get suspend with X running to work and ended up falling back to the already available software suspend. I’ll outline how I got to my stopping point on software suspend 2 after I talk about the suspend that actually works for me. Maybe somebody else can pick up the software suspend 2 process…

Software Suspend working

Getting the natively support software suspend up and running is real simple – and works quite well so I’m not sure what advantages software suspend 2 has over it.

# Install the hibernate script
apt-get install hibernate

Now all we need to do is edit a few files. The /etc/hibernate/hibernate.conf file should be updated to remove references to software suspend 2 properties, and we need to update the /boot/grub/menu.lst file to specify our swap partition.

# Edit /etc/hibernate/hibernate.conf
#
# Comment out the whole first block of software suspend 2 specific properties,
# from "#UseSwsusp2 yes" all the way to "# VerifyFilewriterResume2 yes" 
#
# Add "UseSysfsPowerState disk" 
nano -w /etc/hibernate/hibernate.conf

With all the extraneous comments taken out, my hibernate.conf file looks like this:

UseSysfsPowerState disk

Verbosity 0
LogFile /var/log/hibernate.log
LogVerbosity 1
Distribution debian

UnloadBlacklistedModules yes
LoadModules auto

Now let’s update /boot/grub/menu.lst

# Edit /boot/grub/menu.lst to tell the kernel what partition you want to use to hibernate.
# This should be set to your swap partition.  If you don't know what it is, run
# this command:
#
# cat /etc/fstab | grep swap | cut -c0-12
#
# Add a resume=my_swap_partition argument to the swsuspend kernel line
# Mine looks like this:
#
# kernel  /vmlinuz-2.6.12.6 root=/dev/sda9 resume=/dev/sda3 ro
#
nano -w /boot/grub/menu.lst

Once you’ve done this you’re going to need to reboot into your kernel before you try hibernating (so the resume partition is set). Once you’ve rebooted into your kernel you should be able to run the following as root to hibernate:

/usr/sbin/hibernate

Tada – a hibernating laptop. Man, what a useful feature that you don’t really appreciate till you don’t have it.

Software Suspend 2 not working w/ X

Compile Kernel

What! Compile again? Yeah, I hear ya. That’s life in the Debian-on-a-laptop world. There are quite a few steps involved in getting software suspend working, but the first necessary evil is patching and compiling the kernel.

# I like to copy the existing source to a new directory to work with
cd /usr/src
cp -r linux-2.6.12.6 linux-2.6.12.6.swsuspend

# Make the linux symlink
ln -s /usr/src/linux-2.6.12.swsuspend linux

# Download the software suspend patch for kernel v2.6.12
wget http://www.suspend2.net/downloads/all/software-suspend-2.1.9.9-for-2.6.12.tar.bz2
tar -xvjf software-suspend-2.1.9.9-for-2.6.12.tar.bz2

# Patch the kernel for software suspend
cd /usr/src/linux
../software-suspend-2.1.9.9-for-2.6.12/apply

# Patch mkinitrd
wget http://dagobah.ucc.asn.au/swsusp/2.0.0.102/swsusp-initrd.sh
cp swsusp-initrd.sh /etc/mkinitrd/scripts/
chmod +x /etc/mkinitrd/scripts/swsusp-initrd.sh

# Edit this one kernel source file:
# /usr/src/linux/fs/jffs2/background.c
#
# go to line 95 and change remove the "0" method arg
# from this "if ( try_to_freeze(0))" 
# to this "if ( try_to_freeze())" 
#
# Save the file
#
# OR - download my file with the change already included at
# http://ryandaigle.com/files/linux/background.c
#
nano -w /usr/src/linux/fs/jffs2/background.c

# Compile the kernel with the following settings in the kernel menuconfig:
#
# In the kernel menu config make sure of the following selections
# Power management options ---> Software Suspend 2
# Power management options ---> Software Suspend 2 --> Swap Writer
# Power management options ---> Software Suspend 2 --> Allow Keep Image Mode
# 
# and DE-select
# Power management options ---> Software Suspend (EXPERIMENTAL)
#
make-kpkg clean
make-kpkg --append-to-version -swsuspend --config menuconfig kernel_image kernel_headers

After the compile you should have two deb packages in /usr/src ready to be installed. Let’s do so

cd /usr/src dpkg -i kernel-*2.6.12.6-swsuspend*.deb

You may see the following error when installing kernel-image-2.6.12.6-swsuspend_10.00.Custom_i386.deb

Setting up kernel-image-2.6.12.6-swsuspend (10.00.Custom) ...
/usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
FATAL: Module sd_mod not found.
WARNING: This failure MAY indicate that your kernel will not boot!
but it can also be triggered by needed modules being compiled into
the kernel.
Searching for GRUB installation directory ... found: /boot/grub

It’s OK! The sd_mod module should be built into the kernel and there’s no need to load it as a module.

At this point you need to edit your /boot/grub/menu.lst file and replace all occurances of hda with sda for all kernels listed. Everytime I’ve installed a newly compiled kernel, it has reverted all the kernels listed back to their IDE equivalents, and if you’re on a D610 they’re actually represented as scsi devices.

At this point I like to reboot into my new kernel just to make sure I can run it – you won’t be able to hibernate yet, but at least you’ll know everything else is all right.

Note: When you reboot into your new swsuspend kernel you’re going to have to recompile any modules that you compiled under your old kernel. In my case that included the ieee80211 and ipw2200 wireless modules. Once you’re in your new kernel that should be as easy as:

cd /usr/src/ieee80211-1.1.13
make && make install
cd /usr/src/ipw2200-1.1.0
make && make install

If that doesn’t work for you, see the wireless setup howto in the previous section.

Suspend Configuration

If you’re at this point you should be humming along with your new suspend-enabled kernel. We have to do a few more things before we can actually hibernate, though they’re all pretty simple:

# Edit /boot/grub/menu.lst to tell the kernel what partition you want to use to hibernate.
# This should be set to your swap partition.  If you don't know what it is, run
# this command:
#
# cat /etc/fstab | grep swap | cut -c0-12
#
# Add a resume2=swap:my_swap_partition argument to the swsuspend kernel line
# Mine looks like this:
#
# kernel  /vmlinuz-2.6.12.6-swsuspend root=/dev/sda9 resume2=swap:/dev/sda3 ro
#
nano -w /boot/grub/menu.lst

Now you need to install the hibernate script that actually invokes the suspend functionality. It’s available as a debian package “hibernate”, but I downloaded and installed from the package available on the software suspend site.

cd /usr/src
wget http://download.berlios.de/softwaresuspend/hibernate-script-1.05.tar.gz
tar -xvzf hibernate-script-1.05.tar.gz
cd hibernate-script-1.05
./install.sh
ln -s /usr/local/sbin/hibernate /usr/sbin/hibernate

At this point I attempted to reboot into my new kernel, but was met with the following error:

=== Software Suspend ===
BIG FAT WARNING!! Initrd not properly configured for resuming.

I did some searching and it appears that initrd and software suspend sometimes don’t play nice. I was able to comment out the initrd line in /boot/grub/menu.lst for my kernel so that it looked like this:

kernel  /vmlinuz-2.6.12.6-swsuspend root=/dev/sda9 resume2=swap:/dev/sda3 ro
#initrd /initrd.img-2.6.12.6-swsuspend

With this configuration I was able to boot into the kernel and hibernate from the console, but I could never resume when X was running.

And this is where I stopped with software suspend 2. Let me know if you have better luck…

Next

I foresee X11 and other configs coming soon…

Other Debian Resources

• http://home.comcast.net/~canez/d610/
• http://www.howtoforge.com/forums/showthread.php?t=21
• http://newbiedoc.sourceforge.net/system/kernel-pkg.html

tags: dell latitude, debian, linux, software suspend

From the “I always need this but never remember how to do it” file – How to kill a Linux process from the command line:

ps -A | grep processname | cut -c0-5 | xargs kill

This gets a listing of the process in question from ps -A that looks like this:

17468 ? 00:00:00 processname

and cuts the first five characters to get the process id and passes that straight to kill.

For extra crispiness, use kill -9.

Update: As my fellow readers have pointed out – the killall command already does this. So, don’t write your own and don’t listen to me, just use killall processname

However, if you’re looking to kill only certain processes, and not all processes of the same executable, you can modify the command like this for a more generic matcher patter:

ps -aux | grep process pattern | cut -c10-15 | xargs kill

tags: linux

I’m in the middle of migrating my blog from the fine Java-based blogging app Pebble to the Rails poster-child, Typo. Just time for a change in pace, nothing against Pebble.

So, if you’re seeing this post in your reader chances are you’re also seeing duplicates. Sorry ‘bout that… This also means that I don’t think most of the comments are going to be preserved though I will try pulling over the popular posts so not all is lost.

tags: typo, pebble, blogging