Arch Linux

Theq629

Member

Registered: 2007-01-04

Posts: 10

EEE PC with Luks and Uswsusp

I've just installed Arch on my Asus EEE PC (which works nicely thanks to the packages people have made), and have been trying to get both luks/dm-crypt encrypted disks and uswsusp suspend to disk working.

I've set up encrypted partitions for /home and swap on an SD card, along with unencrypted partitions for / and /boot on the built in drive. The basic set up of the encrypted partitions was done following the wiki article on luks encrypted roots, but I open the swap partition from the encrypt initcpio hook and have uswsusp use /dev/mapper/swap as the resume device.

The append line in my lilo.conf is:

    append="eeesdslotdev=/dev/sdb3@keys cryptdevice=/dev/sdb2:swap"

And my mkinitcpio.conf hooks are:

HOOKS="base udev eeesdslot encrypt ls uresume filesystems"

The 'eeesdslot' hook (with the eeesdslotdev parameter) loads modules seemingly required to make the SD card device show up (specifically usb-storage, ext2, and dependencies) and waits until /dev/sdb2 exists. The 'ls' hook just lists /dev/mapper/* to make sure that swap shows up.

My problem is that uswsusp won't resume even after appearing to suspend properly. The uresume hook doesn't show any error messages, just the little note that says the resume program is running.

As far as I can tell the resume program can access the swap partition during booting, but fails to resume simply because it can't find its signature there. I've checked that /dev/mapper/swap shows up in the output of the ls hook, and modified the resume program to produce extra output which suggests that it is failing at the point where it looks for a signature. I've tried making the suspend program output more information and pause to let me read its output, but so far haven't seen any sign of errors from it.

I had previously had some hibernation attempts abort before shutting down. The hibernate or s2disk commands would appear to get at least as far as generating a resume image, but just after that would just quit. They would also clear the screen, so that I couldn't see any error messages. I believe this problem stopped when I turned off the early writeout option in suspend.conf. I also had exactly one hibernate attempt which resumed properly, although I think the disks may have been in an inconsistent state afterwards. I believe the only thing I had changed before this attempt was my extra debug output lines in the uswsusp programs, so I have no idea what happened.

Thanks for any advice. Also, I'd be interested in hearing if any other EEE users here have tried uswsusp with or with out encrypted drives.

Theq629

Member

Registered: 2007-01-04

Posts: 10

Re: EEE PC with Luks and Uswsusp

I have a little more information now. Firstly, the problem occurs even if I use an unencrypted partition on the SD card.

Second, I have a better idea of what fails. The uswsusp suspend program tries to write its signature "ULSUSPEND" to the swap device, and appears to have succeeded. However, the signature is not present on the swap device after rebooting, even if I boot to the Arch core installer off a USB stick, which presumably does not touch the swap device. Instead of the uswsusp signature, what I take to be a standard swap space signature ("SWAPSPACE2") shows up at the same place on the device. I'm not sure if the actual suspend data is getting written successfully or not.

I'm assuming this means something along the lines of caches not being written to the SD card, but I have no idea what to do about that.

xpd259

Member

From: Bradford, UK

Registered: 2007-12-31

Posts: 11

Website

Re: EEE PC with Luks and Uswsusp

have you had any joy with this?
im looking to have hibernate work with luks on a standard pc but yours is the only post in the forums with luks & hibernate in it :-/

DanielW

Member

Registered: 2008-01-27

Posts: 23

Re: EEE PC with Luks and Uswsusp

Theq629:

I think, you have the same problem than all the other who use the sd card for /home.  Even if you umount it at shutdown normaly, it comes up as not cleanly unmounted. So it comes to get checked on every boot.

It seems that the Cardreader doesn't write all things to the end before the system shutsdown. Some users are saying that it helps to sync, sleep 2, umount, eject, sleep 1  before shutdown. So i think you should try to put these lines somewhere in your hibernate script. (don't sure how exactly the hibernation works, but you must do that excalty before the shutdown.).  mhh can not umount swap, right?  so i think you should try sync, sleep 2, swapoff, eject, sleep 1.

good luck.

DanielW

Theq629

Member

Registered: 2007-01-04

Posts: 10

Re: EEE PC with Luks and Uswsusp

As far as I can tell this isn't the same problem as using the SD card for home, although I'm not sure if I've read everything on that problem. I've started a thread on suspend-devel list about this too.

I do seem to be able to hibernate successfully to a swap partition on the internal drive. In my first tries my /home from a partition on an SD card would appear corrupted after resuming, but if I do

    echo 1 > /sys/bus/usb/devices/usb1/1-5/power/persist

before hibernating then /home seems to come back cleanly. I've been using this setup for a few days now with no problems except maybe with the wireless device.

I'm less worried about hibernating to the SD card now, though. My original reason for wanting to use an SD card for hibernation was mostly the stories about the internal drive wearing out, and this doesn't sound like a real problem any more. And the internal drive is probably faster to suspend to as well.

Thanks in any case.

Theq629

Member

Registered: 2007-01-04

Posts: 10

Re: EEE PC with Luks and Uswsusp

xpd259:

I haven't actually tried the luks part since I've had the uswsusp part working (on the internal drive), but as far as I could tell the luks part was working for me earlier. I'll try it again and write up something if there's no documentation. As far as I remember I had to do some manual digging around in /lib/initcpio/hooks/encrypt to find out how the encrypt hook was supposed to work.

dkite

Member

Registered: 2007-06-01

Posts: 62

Re: EEE PC with Luks and Uswsusp

I'm less worried about hibernating to the SD card now, though. My original reason for wanting to use an SD card for hibernation was mostly the stories about the internal drive wearing out, and this doesn't sound like a real problem any more. And the internal drive is probably faster to suspend to as well.

Thanks in any case.

How big did you make the swap partition on your internal drive?

Derek

Theq629

Member

Registered: 2007-01-04

Posts: 10

Re: EEE PC with Luks and Uswsusp

How big did you make the swap partition on your internal drive?

Derek

It's 512MB.

Theq629

Member

Registered: 2007-01-04

Posts: 10

Re: EEE PC with Luks and Uswsusp

Encryption does seem to work for me, though I've only given it a quick test so far. I'm using uswsusp and have it ask for a password at boot (no key files or anything). It's basically just a matter of using the cryptdevice parameter to the encrypt hook, but here's my full procedure.

Set up an encrypted partition normally, open it manually, and format it as swap:

cryptsetup luksFormat /dev/sda3
cryptsetup luksOpen /dev/sda3 swap
mkswap /dev/mapper/swap

Edit fstab to use /dev/mapper/swap as swap. Edit suspend.conf to use /dev/mapper/swap. Add the 'encrypt' hook before the 'uresume' hook in mkinitcpio.conf. Add an append item to lilo.conf:

append="cryptdevice=/dev/sda3:swap"

Regenerate the kernel image, and run lilo.

thetrivialstuff

Member

Registered: 2006-05-10

Posts: 191

Re: EEE PC with Luks and Uswsusp

Bump -- I was just trying to do a similar setup to this; this worked reasonably well, but before I found it I had come up with another way of doing the same thing (encrypted hibernation with encrypted swap):

#!/bin/bash

#convert swap to non-encrypted so that uresume can find & reload it
echo DOING: swapoff /dev/mapper/swap
swapoff /dev/mapper/swap
echo "Waiting 1 sec for device mapper (or something) to catch up..."
sleep 1
echo DOING: cryptsetup luksClose swap
cryptsetup luksClose swap
echo DOING: mkswap /dev/sda5
mkswap /dev/sda5
echo DOING: swapon /dev/sda5
swapon /dev/sda5
sync
s2disk
#system is now asleep. When it wakes up, it will resume execution from here:
echo 
echo "...and we're back!"
echo
echo DOING: swapoff /dev/sda5
swapoff /dev/sda5
echo DOING: cryptsetup
cryptsetup -d /dev/urandom -c aes-cbc-essiv:sha256 -s 256 create swap /dev/sda5
echo DOING: /sbin/mkswap -f -L swap /dev/mapper/swap 
/sbin/mkswap -f -L swap /dev/mapper/swap
echo DOING: swapon /dev/mapper/swap
swapon /dev/mapper/swap
echo all done.

Advantages:
- You only ever enter one decryption password at boot -- if it's a fresh boot, swap gets auto-created by crypttab/rc.sysinit and you're prompted for the decrypt password for root (or whatever partition you've got encrypted). If it's a resumed boot, uresume asks you for the password to the resume image (and the system starts up with the encrypted partitions already loaded because the keys were in memory before).
- uresume can handle the resuming all by itself, making the bootup a little less complex (in my case, root is not encrypted so there's no need for the encrypt hook)

Disadvantages:
- Lots of swapon and swapoff might make this slightly slower -- swap partition has to be cleared and re-created before s2disk can work
- Slight chance that during the script above (just before sleeping or just after waking) unencrypted data might find its way onto the unencrypted swap before it's cleared and re-encrypted. (seems unlikely though)

Theq629

Member

Registered: 2007-01-04

Posts: 10

Re: EEE PC with Luks and Uswsusp

- Slight chance that during the script above (just before sleeping or just after waking) unencrypted data might find its way onto the unencrypted swap before it's cleared and re-encrypted. (seems unlikely though)

I thought about doing something like what you describe, but decided against it for that last reason. The encrypt hook seems to run fast, so I don't mind using it.

While this thread has been revived, I will note that I am still using basically what I described above, with a single encrypted swap partition on the internal drive used for both regular swap and suspending. I am using a custom mkinitcpio hook to prepare the swap device before the resume hook (and the encrypt hook, in my case) is called. As far as I recall some of the standard hooks (possibly the file system ones) also do the job, but they do extra work and so making my own sped up the boot process. This is the mkinitcpio hook, called prepareresume:

# vim: set ft=sh:
run_hook ()
{
    set -- $(/bin/replace "${resumedevice}" ':'); name=$1; type=$2; major=$3; minor=$4
    /bin/mknod $name $type $major $minor

    /bin/mknod /dev/snapshot c 10 231
}

This is the hooks in mkinitcpio.conf:

HOOKS="base prepareresume encrypt uresume"

And this is the parameters from lilo.conf:

append="resumedevice=/dev/sda3:b:8:3 cryptdevice=/dev/sda3:swap"

Last edited by Theq629 (2009-09-22 06:45:14)