# suspend to disk without initrd

## John Malc

Hi...

My setup is as simple as possible:

Grub, boot partition with bzImage, separate partition with root fs.

I don't have an initrd, which works fine for me.

My kernel has the AHCI drivers and ext4 drivers compiled-in, this is enough for the kernel to start up and access the root and load the rest of the modules.

On kernel update I just compile, swap out the bzImage file and I'm done.

This works now for ~15 years just fine :-)

Now... I want to do suspend to disk.

Hibernate-to-ram works fine, however with flying it is annoying to completely shutdown and reboot.

Suspend-to-disk would be fine, with SSDs read/write speed should not be a problem.

Question:

Is suspend-to-disk even possible with my setup?

I find for Gentoo quite a few tutorials, however they explain suspend with kernel patching, rebuilding of initrd etc. etc.

Keep it simple - do I really need an initrd or patch the kernel?

If it is possible, can one point me to a proper tutorial for Gentoo how this is done in my setup?

Thank you - and I hope I can play with this over the holiday days :-)

John

----------

## Yamakuzure

You do not need an initrd for suspending to disk, but a swap partition that is large enough to hold the total of your memory (plus some reserve maybe.)

Best kernel patchset would be TuxOnIce, either with sys-kernel/tuxonice-sources or, if you dare, sys-kernel/geek-sources from init6 overlay. You'd need then sys-apps/tuxonice-userui, and that's it.

----------

## John Malc

thanks, so it is possible :-)

Since I need a really brand-new kernel for this Haswell box, is there also a way without kernel patching?

Is there a way with a standard kernel with just resume=....?

Do I need to patch anything else in Gentoo boot-up scripts?

----------

## Yamakuzure

suspend to ram is easy, just use sys-power/hibernate-script. But suspending to disk is a trickier thing. Please read the TuxOnIce Wikipedia Article before deciding against TOI.

You do not need to patch the kernel yourself. sys-kernel/tuxonice-sources is just the same as sys-kernel/gentoo-sources plus the TOI patches. And the system restarts the suspended session automatically with no action needed. All you need to configure is

```
CONFIG_PM_STD_PARTITION="/dev/<your swap partition>"
```

in /usr/src/linux/.config.

Oh, and Haswell is supported since kernel 3.10, so you should be fine here, no super-new-just-committed kernel needed.  :Wink: 

----------

## John Malc

Thank you very much!

I will try during the holidays :-)

(and my shiny new Haswell laptop needs minimum 3.12 or power-management and audio is not working properly...)

----------

## szatox

Audio in gentoo just is  a bit problematic. In all my pcs I had to tweak /etc/modprobe.d/alsa.conf to make it work (alias and index). Wooden laptop, 3 years old laptop and fairly new box. Weird, as debian autodetected both laptops correctly (haven't tested on box). Anyway, check this out

----------

## Yamakuzure

If you are using Intel HD Audio, make sure to enable only the providers you actually can use. Then it should be no problem.

For instance, on my Dell Laptop, audio works fine with the following configuration:

```
 ~ $ grep -i alsa /etc/portage/make.conf

ALSA_CARDS="hda-intel"

 ~ # grep SND_HDA /usr/src/linux/.config

CONFIG_SND_HDA_INTEL=m

CONFIG_SND_HDA_PREALLOC_SIZE=2048

# CONFIG_SND_HDA_HWDEP is not set

# CONFIG_SND_HDA_INPUT_BEEP is not set

CONFIG_SND_HDA_INPUT_JACK=y

# CONFIG_SND_HDA_PATCH_LOADER is not set

# CONFIG_SND_HDA_CODEC_REALTEK is not set

# CONFIG_SND_HDA_CODEC_ANALOG is not set

CONFIG_SND_HDA_CODEC_SIGMATEL=y

# CONFIG_SND_HDA_CODEC_VIA is not set

CONFIG_SND_HDA_CODEC_HDMI=y

CONFIG_SND_HDA_I915=y

# CONFIG_SND_HDA_CODEC_CIRRUS is not set

# CONFIG_SND_HDA_CODEC_CONEXANT is not set

# CONFIG_SND_HDA_CODEC_CA0110 is not set

# CONFIG_SND_HDA_CODEC_CA0132 is not set

# CONFIG_SND_HDA_CODEC_CMEDIA is not set

# CONFIG_SND_HDA_CODEC_SI3054 is not set

CONFIG_SND_HDA_GENERIC=y

CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
```

But Audio stays silent if I activate CONFIG_SND_HDA_CODEC_REALTEK or CONFIG_SND_HDA_CODEC_CMEDIA.

----------

## Hu

You can use a mainline kernel and still use suspend-to-disk.  It should work with just a resume= line.  However, if you do this, it is difficult to secure the hibernation image.  Any content in memory at hibernation time will be written to the swap device unencrypted and will not be wiped on resume.

----------

## Yamakuzure

 *Hu wrote:*   

> You can use a mainline kernel and still use suspend-to-disk.  It should work with just a resume= line.  However, if you do this, it is difficult to secure the hibernation image.  Any content in memory at hibernation time will be written to the swap device unencrypted and will not be wiped on resume.

 Yes. And if your swap space is too extensively used at that moment, your machine will crash half way through the write. (Stupid thing to try anyway.)

----------

## toralf

Just use

```
echo 0 > /sys/power/image_size
```

in /etc/acpi/default.sh or somewhere else - works fine with a newer vanilla kernel and avoids a lot of s2disk problems. I do use the standard kernel since years for s2ram and s2disk and just make a 

```
echo $1 > /sys/power/state
```

in /etc/acpi/default.sh, where $1 is eiether "mem" or "disk" eventually. I putted few more pre/post tasks into that script for my needs (http://bpaste.net/show/160432/)

----------

## John Malc

Programs in memory usually only use one third of main mem, rest is disk cache. So to my understanding it would be natural to first throw out all the things from memory which can be easily reloaded - caches - the remaining rest should fit easily into the swap area.

That the resume image is in plain, yeah, that is a general concern with suspend, but I guess setting everything up encrypted, also the root partition, makes things much more complicated. So far the data partition is encrypted and that should be enough for the expected thief-steals-laptop-from-hotel-room situation.

----------

## Hu

An encrypted data partition will still be accessible after resume.  The thief would need to log in or otherwise obtain code execution.

A fully encrypted setup is quite workable and I find the complexity to be reasonable.

----------

## John Malc

sooo... reporting back :-)

I increased swap to main mem+2Gb.

hibernate-ram always worked fine

hibernate alone works also, the only thing required is the "resume=/dev/swap" line in Grub

yay! :-)

...and it runs quite ok, hibernation time is not much different from ram to disk,

however with wakeup, from ram is 1-2s, while from disk is ~10s to Grub prompt and another ~8-10s till desktop appears (SSDs with 500Mb/s read are fun :-)

I also learned that the swap partition supports "discard", which means a TRIM is run on swapon.

Consequently, the commands should be "hibernate; swapoff -a; swapon -a" which should TRIM the hibernation image.

This is only kind-of security as this depends on the actual SSD behaviour, the data may well continue to exist for some time, but better than nothing.

Intuitively, I guess encrypted swap is not possible with my setup as this would require to enter a swap encryption key somewhere on bootup, but without initrd I guess this is not possible.

So far the system appears to be the same coming back from ram or disk, with one observed difference, that the CPU speed in /proc/cpuinfo is lowest from disk, but highest from ram. However, as written elsewhere, maybe that's the p-state driver on Haswell with 3.12 and the values don't really matter there.

In summary, I learned something and can now work with hibernation.

The security with the swapfile relying on TRIM is not that good, but blowing away several Gb of SSD life with wiping swap with zero after every hibernate does not sound good either.

Guess one day I'll have make the trade-off boot complexity with initrd and security....

----------

## Hu

If you encrypt your swap device, then there would be no need to wipe it after each resume.  The swapped data would be as (in)secure as the key to the encrypted swap device.

However, you are correct that there is no way to use encrypted swap without some sort of early userspace to prepare the decryption key for resume.

----------

