[Bug 554009] Re: Resume from disk (swapfile) fails

[Scott James Remnant]

On Thu, 2010-04-22 at 06:28 +0000, Moreno Bartalucci wrote:

> As I stated in my original bug report, resuming from swapfile used to work correctly on karmic: why do you say you don't support it? Do you mean: you don't support it anymore?
> 
No, I mean we've never supported this.  We've never put any effort into
making it work, we don't test to make sure it works, and as far as we
know, it doesn't work.

We discussed doing the work in both Karmic and Lucid, but developers
haven't had the time.

If it worked for you before, that was more out of luck than intent ;-)

> so, in my opinion, resuming from swapfiles *should* be supported.
> 
I don't disagree at all!  We want to support swap files, and resuming
from them, we just haven't done the work yet.


> At the end of the script '/usr/share/initramfs-tools/scripts/local-
> premount/resume', you can find this:
> 
> SWAPTYPE=$(wait-for-root "${resume}" ${RESUMEDELAY:-5})
> 
> case "${SWAPTYPE}" in
>     swsuspend|s1suspend|s2suspend|ulsuspend|tuxonice)
>         if [ -x /bin/plymouth ] && plymouth --ping; then
>                 plymouth message --text="Resuming from $resume"
>         fi
> 
>         # hardcode path, uswsusp ships an resume binary too
>         if [ -n "${resume_offset}" ]; then
>                 /bin/resume ${resume} ${resume_offset} >/dev/null 2>&1
>         else
>                 /bin/resume ${resume} >/dev/null 2>&1
>         fi
>         ;;
> esac
> 
> So: 'wait-for-root' does *NOT* only wait for the partition to become active, it also detects *IF* any hybernation occurred and it decides the kind of hybernation data.
> 
Actually it doesn't

wait-for-root simply returns the block device type as probed by udev, it
doesn't do any probing of its own.  udev obviously doesn't know about
the resume offset.

> Question: if 'wait-for-root' doen't know about the offset of my swapfile, how can it know if my pc was hybernated or not?
> 
As mentioned above, wait-for-root doesn't probe; it's simply a
replacement for a while loop done in shell to wait for device nodes to
appear.

In fact, in your case, it's almost certainly better than the previous
shell since it will return immediately and make resume faster (if the
other bit worked).


> The 'resume' program, in my case and in my opinion, is *NOT* executed at all, so it can't be its fault.
> 
This bit confuses me; your bug reports includes the following messages
from dmesg:

[ 0.778970] PM: Checking image partition UUID=f0e784ed-e140-4d73-87a3-8ef047012b9f
[ 0.785267] PM: Resume from disk failed.

Doesn't this come from the "resume" program?


> Thank you for your help on this matter, I really appreciate it!
> 
So the problem with this script is that the script is only written to
assume resume-from-block device.  It uses the udev probed block device
type to determine whether to run "resume" or not.

It should have a fallback for the case of swap-file (which I guess is
resume_offset is set?) that calls resume directly and ignores the
returned filesystem type.

Of course, this is still a hack - in order to support resume from swap
file properly, we need to not require resume_offset but auto-detect it;
there are runes for that somewhere on the Internet.

Scott
-- 
Scott James Remnant
scott at ubuntu.com

-- 
Resume from disk (swapfile) fails
https://bugs.launchpad.net/bugs/554009
You received this bug notification because you are a member of Kernel
Bugs, which is subscribed to initramfs-tools in ubuntu.