Not sure about kernel 3.0.x, but I will describe some methods for the
2.6.30+ kernels that I use with initramfs-tools-0.98. You most likely
have to modify and adapt things to suit your versions. Read carefully
and proceed (at your own risk) only if you know what you are doing.
When multiple swaps are active and you hibernate using the kernel's
built-in method (in pm-utils terms, SLEEP_MODULE="kernel", not
"uswsusp" or "tuxonice"), the kernel will randomly choose one of your
active swap devices to store the snapshot image (AFAIK, there is no way
to force the kernel to use a specific swap device). So resume will only
work if that device happens to be the same one as the one configured
via the "resume=<swapdev>" initramfs parameter (which is specified
either via "RESUME=..." in /etc/initramfs-tools/conf.d/resume, or via
grub2 config /etc/default/grub, or manually at the grub boot screen,
with each of these directives overriding the preceding ones).
Unfortunately, under normal conditions the kernel does not notify you
which partition it uses for hibernation. Here are some things to consider.
I will assume only swap partitions are being used --- no swap files.
(A) Quick and dirty manual recovery to resume:
DANGER, WILL ROBINSON!! READ THE WARNINGS BELOW!
If you hibernated while multiple swap partitions were active and still
want to resume, a quick and dirty manual method is to boot into the
initramfs "premount" break-poiint shell (boot parameter break=premount),
and run: blkid -t TYPE=swsusp (or run blkid | grep swsusp), which should
identify the unique partition where the hibernation image is stored.
[Note: Having multiple such partitions is a serious error condition
which should never happen and your only course of action then would be
to do a normal boot and making sure that the suspend signatures on those
partitions are erased (automatically done if those partitions are used as swap).
Also, if the blkid command above does not return anything you have to
do a normal boot; just exit out of the initramfs shell or reboot.]
Next, identify the major and minor numbers m:n for that partition from
/sys/class/block/sdaXY/dev (cat that file).
Finally, echo the major:minor numbers (in the format m:n) onto
/sys/power/resume. If everything has been done right, it should
perform a proper resume
Note again that these steps are valid only if the kernel's internal
hibernation method was used (when using userland uswsusp, the
command to manually resume is /sbin/resume -r <resume_dev>).
[One can even automate the above manual procedure by adding
an initramfs boot script which runs at the end of premount phase,
after resume via kernel/uswsusp has been tried. Such a script can
detect the presence of a unique "swsusp" swap partition (_after_
the initramfs premount resume/uswsusp boot scripts have
attempted to resume but have returned) and give the user
the option of either attempting a resume from that "swsusp"
partition, or proceeding to a normal boot (echo "if unsure, do
normal boot"). But unless carefully written, such a script can
introduce additional security or other vulnerabilities, see the
warnings below.]
WARNING, USE AT YOUR OWN RISK:
The above manual resume assumes that nothing has touched the disk
between your last hibernation and the manual resume (no mounting of
any partition, no boot from liveCD/USB, etc). Resuming after your disk
has been touched in some way or resuming with a wrong/stale snapshot
image will cause severe damage to your filesystems --- much more severe
than a "normal boot without resume" (which initially checks filesystems)
where you may loose your session but have generally limited damage to
your filesystems. If unsure, it is safer to do a normal boot.
MORE WARNING:
Even after a normal boot, there are additional risks to consider: Unless
all your swap devices are listed in /etc/fstab as swaps to be activated
(i.e. without the noauto option), there is a risk of having a stale snapshot
image remaining between boots and normal use (since mountall/swapon -a
will not clear the SIG_SUSPEND suspend signature) and a later configuration
change can cause a resume from that old image leading to disaster.
Consider having a special script which is run both at normal boot and
before and after each hibernation) manually doing a "swapon;swaoff"
on every swap partition on disk that is not being actively used as swap.
(B) Use userland uswsusp method
Unlike the "kernel" hibernation method, this allows you to choose
a specific swap device for hibernation, giving you more flexibility.
[You can even use the kernel method and the uswsusp method
parallely (I do, with different swap partitions assigned to them,
but additional bookkeeping and check scripts are needed).]
But (especially when using multiple swap devices) a misconfiguration
can result in an "out-of-sync" condition between uswsusp's master
config file (/etc/uswsusp.conf or /etc/suspend.conf) on disk filesystem
and its copy in the initramfs image. So the warnings above stiil apply
for userland uswsusp. A quick shell check for that is:
[ "/etc/uswsusp.conf" -ot "/boot/initrd.img-$(uname -r)" ] && \
[ "/boot/initrd.img-$(uname -r)" -ot "/boot/grub/grub.cfg" ].
An additional check would make things stricter:
cat "/boot/initrd.img-$(uname -r)" | \
gzip -cd | \
cpio -i --to-stdout "etc/uswsusp.conf" 2>/dev/null | \
diff - "/etc/uswsusp.conf"
One can put such checks in /etc/pm/sleep.d if pm-utils is
being used.
PS. The entire complication arises because there is no
unique standardized location on the boot hard disk where
a pointer to the hibernation image information is stored.
E.g., the first sector is used as the agreed upon location
to store the master boot record consisting of boot loader
code and the primary partition table. Oh well.
.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/923326
Title:
With multiple swap partitions resume from hibenation fails
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/923326/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
