I would like to know how the snapshot of the system is taken during hibernation(S2disk) which is then stored in the swap partition.A typical /etc/suspend.conf shows that the snapshot device to be used is set to /dev/snapshot. Please suggest something to make my understanding better as to how the snaphot image is created and exactly how it is stored at its position which is then loaded into memory on resume(resume device parameter embedded into initramfs).

As I understand it, the system at any point has a kernel running and stuff loaded in relevant spots. By putting these things back in memory exactly as they were and telling everything where to take up, you _should_ be back to where you were before the suspend.

In fact it never works as cleanly as that(Murphy's Law), and there's 'glue software' to fix that.

Thanks for the reply.

As you explained,the contents of RAM as they were before suspend are stored in swap and on resume the kernel loads them into memory again on resume to give us a feeling of a new kernel being loaded and resume to the state as we suspended in.

My question is how exactly is this snapshot taken and saved into the swap partition? And at what point during boot is this image loaded into the memory?

Isn't this the beauty os Open Source, that you can look at the code for yourself and figure these things out? I never bothered, once it worked. If you boot, suspend, & resume then the dmesg output carries a blow by blow as it unhooks usb, etc.

If you tell us why you need this information, we may be able to help.

Thanks for the reply.

Well my long goal is to achieve a kind of hybrid between hibernation and shutdown where I close all the user-space program before powering down the system and also create a hibernation image. We use this image to the boot the system.

I am in the initial stage of learning the mechanism of S2disk and studying the role played by pm-utils,ACPI and initramfs.Right now I am trying to locate the process/code responsible for the creation of image and storing it in the swap.I hope this gives a broad idea of the work.

To quote the Irishman when asked for directions:
"If I was you, I wouldn't start from here at all!"

Suspend and resume are major deals requiring balancing of all sorts of things. They were developed over years by project teams. For instance, the original APM implementation couldn't effectively handle IBM Thinkpads, which broke a number of expected norms and created havoc with interrupts. So it was dropped, and a whole new approach (acpi) was started, which initially was worse on many boxes.

You don't need a suspend, or hibernate. You want switch off,and autostart, and something like initng which boots and shuts down quicker. The beauty of suspend and hibernate is that you stay there with your same lusers logged into the same places, same programs running, reading same files, with environment variables intact, etc. This is behaviour you do not want.

Suspend and hibernate are hardware dependent. Programs designed to implement an interface between the operating system and hardware facilities for suspend/hibernate must comply to the relevant hardware, because it is the basis of those functions.

Neither is designed to boot a cold system. Hibernate begins to load the system image by a makeshift init linked to /sbin/init, in a conditional way, so if it fails, the system is recoverable.

Of course, it doesn't work that way, but that's the goal.