Comment 15 for bug 342096

Trying to solve the issue I played (on a Aspire One A110, with 9.04 UNR, and /home on a ext4 partition on a SD card) around with delaying the resume process by making a pm hook (called /etc/pm/sleep.d/99zleep -> so really the first hook that should be read on a resume) containing only a sleep command on thaw|resume. Having a delay of 20 seconds (you have to start somewhere ;-)), you see a whole lot of messages popping up on the screen (that I could not find back in my logs actually) and something odd struck my eye: immediately after resume the kernel finds a new SD card (instead of recognizing it as the old one) and puts it on /dev/mmcblk1 (while it was on /dev/mmcblk0). So what dsaxena saw on a OLPC apparently also happens on our systems.

I decided to unmount the /home before suspend and mount it again after resume, by including umount -l /home and mount /home in my 99zleep hook (as mounting occurs by UUID it does not matter that the location was switched). If you reduce the sleep time to 1 s (on longer times the machine got stuck), it is able to resume, however it does not resume your session but starts a new one by resuming into the gdm greeter. Making the sleep time shorter (to 0.5 s) the behaviour looks better -> resumes your session, however screws up the partition table again: so as soon as you want to switch off the system it hangs and on a restart the partition table of the SD card is gone again (in some cases it also damaged the journal).
I think I need the pause still earlier than I do now (so the SD card is recognized as being the same that was already there), has anybody an idea how to include a pause at the very beginning of the resume script -> before remounting any of the drives?