# [SOLVED] pm-hibernate - slow resume caused by cfg80211

## mutehim

Hi there,

after years of abstinence i want back to gentoo. I am pretty impressed about portage working more flawlessly then i remembered. Anyway, i have an encrypted drive setup using cryptsetup with luks.

Therefore i have my own initram to mount my root ang get the keyfiles for all other devices including the swap.

Now, i want to hibernate. I figured out, that my swap (/dev/mapper/luksSwap) has the internal number 254:1.

When i enter (echo 254:1 > /sys/power/resume) on the busybox after mounting all my encrypted stuff everything works fine, but to slow.

So my questions are:

- What is the proper way to figure out the drive numer (254:1) - i pretty much guessed by looking in the folder /sys/dev/block?

- What happens if i resume from swap without having hibernated? Is there a check to perform before doing resume?

- Resuming takes twice as long as hibernating. Is there a way to debug this?

If i get this done right, i will write a short howto since using encrypted swap for hibernation is a not well covered topic without using genkernel.

Thanks in advance.

My init-file looks like:

```

#!/bin/busybox sh

TARGET=/dev/sda6

NAME=luksRoot

MAP=/dev/mapper/$NAME

ROOT=/mnt/root

INIT=/sbin/init

SWAP=/dev/sda5

SWAPMAP=luksSwap

SWAPKEY=/root/luks/swap

SWAPKEY=$ROOT/$SWAPKEY

mount -t proc proc /proc

mount -t sysfs sysfs /sys

mount -t devtmpfs none /dev

/sbin/cryptsetup luksOpen $TARGET $NAME

if [ ! -d $ROOT ]; then mkdir $ROOT; fi

mount $MAP $ROOT

/sbin/cryptsetup luksOpen -d $SWAPKEY $SWAP $SWAPMAP

#debug 

/bin/busybox sh

echo 254:1 /sys/power/resume

umount /dev 

umount /proc

umount /sys

exec switch_root $ROOT $INIT

```

Sorry for my english.

MLast edited by mutehim on Wed Jun 19, 2013 10:27 am; edited 1 time in total

----------

## Hu

If I am interpreting your initramfs correctly, you have designed it to cause filesystem corruption on resume.  When you boot to resume, you must not mount any filesystems which were mounted at hibernation time.

----------

## mutehim

 *Quote:*   

> If I am interpreting your initramfs correctly, you have designed it to cause filesystem corruption on resume

 

not particularly  :Smile:  - honestly i have not thought about that, stupid ... 

Does a readonly mount cause corruptions aswell?

I guess it is not possible to store the keyfiles on the root-system if i want to resume the system without datacorrution. Therefore i changed my init to mount a encrypted container directly stored in the initram, which holds the two keys for my root and swap device.

Now it look like:

```

#!/bin/busybox sh

TARGET=/dev/sda9

NAME=luksRoot

MAP=/dev/mapper/$NAME

ROOT=/mnt/root

INIT=/sbin/init

KEYFILE=/keycont

SWAP=/dev/sda5

SWAPMAP=luksSwap

SWAPKEY=/mnt/keys/swap

ROOTKEY=/mnt/keys/root

mount -t proc proc /proc

mount -t sysfs sysfs /sys

mount -t devtmpfs none /dev

echo "Setting up loopback device"

losetup /dev/loop0 /keycont

echo "Open container"

/sbin/cryptsetup luksOpen /dev/loop0 luksKeys

mount -o ro /dev/mapper/luksKeys /mnt/keys

echo "Opening Swap"

/sbin/cryptsetup luksOpen -d $SWAPKEY $SWAP $SWAPMAP

echo "copy root keyfile"

# Here, i copy the key because i want to unmount the container, but i dont want to open the device yet.

cp $ROOTKEY /tmp/root

ROOTKEY=/tmp/root

# is this a security risk?

echo "Unmount key container"

umount /mnt/keys

cryptsetup luksClose luksKeys

losetup -d /dev/loop0

echo "Trying to resume"

echo 254:1 > /sys/power/resume

echo "Boot from root"

/sbin/cryptsetup luksOpen -d $ROOTKEY $TARGET $NAME

mount $MAP $ROOT

umount /dev

umount /proc

umount /sys

exec switch_root $ROOT $INIT

```

Hopefully this is more likely designed to boot my system than to corrupt it.

Anyway. It boots fine and resume works aswell but, again, very slow (2-3 times the hibernation time).

Thanks!

Edit:

I can answer most of my (stupid) questions by myself now:

Q&A:

What is the proper way to figure out the drive numer (254:1) - i pretty much guessed by looking in the folder /sys/dev/block? 

```
 ls -l /dev/mapper/luksRoot 

brw------- 1 root root 254, 1 Jun 18 21:33 /dev/mapper/luksSwap

```

There we are => (254:1)

What happens if i resume from swap without having hibernated? Is there a check to perform before doing resume?

Seems like the kernel does this check and there is no need to treat this, right?

Resuming takes twice as long as hibernating. Is there a way to debug this? 

Yes, use dmesg. In my case, time was wasted by cfg80211 which is used by the Networkmanager.

In my case adding 

```
 echo "RestartServices NetworkManager NetworkManagerDispatcher"

 >> /etc/hibernate/common.conf
```

solved the problem.

Besides no confirmation for b) and the question wheater or not it is save to readonly mount a used filesystem i am done. Thanks

----------

