pm-utils doesn't detect uswsusp in hardy

[Benoit Grégoire]

Binary package hint: pm-utils

pm-utils does not detect the presence of uswsusp (it looks for uswsusp binaries (s2disk, s2ram, s2both) in /usr/sbin instead of /sbin), resulting in Suspend and Hibernate using pm-utils's default method. For some users (those whose systems cannot suspend/hibernate without uswsusp), this means that Suspend/Hibernate is completely broken for them. For other users, uswsusp just isn't used, which leads to a longer hibernate/resume time.

In the development branch, pm-utils had been upgraded to 1.1.2.4-1ubuntu1, i.e. new release. The relevant patches that had errors with them, i.e. 10-uswsusp-support.patch, 30-comment-defaults-file.patch and 60-suspend-hybrid.patch were obsoleted in 1.1.0-1.

A debdiff fixing the patches mentioned above, and the corresponding build log has been attached, see comments 2 and 4.

TEST CASE: Install uswsusp, then hibernate the system. Upon resuming, run the command "dmesg | grep swsusp". That should tell whether or not uswsusp was used when hibernating, i.e. no output means uswsusp wasn't used.

Regression potential: since the pm-utils bug prevented uswsusp from receiving widespread testing, it's possible that bugs in uswsusp will cause suspend failures now for users who have it installed where no such failures occurred before.

Current workaround:
- Replace all instances of /usr/sbin/s2{disk,both,ram} with /sbin/s2{disk,both,ram}:
sudo find /usr/lib/pm-utils/ -type f -exec sed -R -i -e 's|/usr/sbin/s2|/sbin/s2|g' '{}' \;

[Chow Loong Jin (hyperair)]

The above workaround worked, and I've created a debdiff for a new package of pm-utils which will fix this issue (sets the default S2DISK_BIN to /sbin/s2disk. I'd appreciate it if someone could test it for me.

Also, while my Lenovo Y410 can hibernate without the help of uswsusp, it takes a long time to resume (~60 seconds). With uswsusp installed (and enabled), it only takes ~20 seconds.

[Chow Loong Jin (hyperair)]

Uh whoops. Forgot to attach it.

[Chow Loong Jin (hyperair)]

I'm assigning it to ubuntu-core-dev since it seems to be a packaging problem and the maintainer of the package is shown to be them.

[Chow Loong Jin (hyperair)]

Attaching build log

[Scott Kitterman (kitterman)]

The appropriate action is to subscribe ubuntu-main-sponsors.

[Chow Loong Jin (hyperair)]

Assigning to ubuntu-main-sponsors as said by Scott Kitterman

[Martin Pitt (pitti)]

This is already fixed in the intrepid version, where the commands are searched in $PATH.

If anyone wants to own the SRU for hardy, please go ahead (i. e. coordinate testing, etc.)

[Chow Loong Jin (hyperair)]

Updated debdiff to show bug number.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

No, really, please *don't* assign a team such as ubuntu-core-dev to a bug. It contains many, many people, most who don't care at all about this package. Thus, it's effectively spam!

[Chow Loong Jin (hyperair)]

Might I point out that you're kind of late saying that? According to the timestamps, the error had already been fixed some 18 hours before that post. This kind of redundancy is unnecessary, unwanted, and hence, effectively spam.

[Steve Langasek (vorlon)]

I've updated the bug description to make it clear that there *is* regression potential here. Indeed, the regression potential may be very broad, and is difficult to quantify at all, precisely because such a bug would have prevented testing in hardy (or, it appears, in gutsy) to confirm that uswsusp works.

As such, I'm concerned that this may not be appropriate material for an SRU at all.

[Chow Loong Jin (hyperair)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Langasek wrote:
> I've updated the bug description to make it clear that there *is*
> regression potential here. Indeed, the regression potential may be very
> broad, and is difficult to quantify at all, precisely because such a bug
> would have prevented testing in hardy (or, it appears, in gutsy) to
> confirm that uswsusp works.
>
> As such, I'm concerned that this may not be appropriate material for an
> SRU at all.
>
If that's the case, are you saying that pm-utils should be left in its current, broken state? While
uswsusp might break for people who already have installed it, mistakenly, there are cases where
people cannot hibernate without using uswsusp (and hence applying some workaround listed above which
may or may not break future upgrades). Are you going to leave it like that, instead of getting the
people who have already, mistakenly installed uswsusp to uninstall uswsusp?

Another thing is that if this issue is left as it is, and users for whom uswsusp is broken upgrade
to Intrepid, where there's a new version of pm-utils which correctly utilizes uswsusp, then it's
going to get a whole lot of bug reports and/or complaints/negative blog/forum posts saying that
"Intrepid broke my hibernate!"

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIvzDG4LFcUo8CpBERAp+aAJ9N1JOkgbhmj1SS3Zdgk5x46cuFLQCggU0K
xuNhuZGBBDyzrIen3jVc3eY=
=Bqw8
-----END PGP SIGNATURE-----

[Martin Pitt (pitti)]

hyperair [2008-09-04 0:50 -0000]:
> Another thing is that if this issue is left as it is, and users for
> whom uswsusp is broken upgrade to Intrepid, where there's a new
> version of pm-utils which correctly utilizes uswsusp, then it's
> going to get a whole lot of bug reports and/or complaints/negative
> blog/forum posts saying that "Intrepid broke my hibernate!"

But imagine the bad press we would (rightfully) get if we broke
*hardy* in the same way, a release which is supposed to be very stable
and rock solid...

While I appreciate your concerns, the principle of SRUs has always
been that the first priority is to not break existing things. It is
so much better and reliable to leave broken things broken than to
break things which have worked fine before.

[Chow Loong Jin (hyperair)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pitt wrote:
> hyperair [2008-09-04 0:50 -0000]:
>> Another thing is that if this issue is left as it is, and users for
>> whom uswsusp is broken upgrade to Intrepid, where there's a new
>> version of pm-utils which correctly utilizes uswsusp, then it's
>> going to get a whole lot of bug reports and/or complaints/negative
>> blog/forum posts saying that "Intrepid broke my hibernate!"
>
> But imagine the bad press we would (rightfully) get if we broke
> *hardy* in the same way, a release which is supposed to be very stable
> and rock solid...
>
> While I appreciate your concerns, the principle of SRUs has always
> been that the first priority is to not break existing things. It is
> so much better and reliable to leave broken things broken than to
> break things which have worked fine before.
>
"Things which have worked fine before." Like what? Installing uswsusp and hibernate apparently
working? (it'd have worked just the same without uswsusp installed because Hardy's pm-utils doesn't
work)

What I'm trying to say here is that the regression we're talking about now will only happens to
users who had already installed uswsusp. These users are either rare, or already know the
consequences of installing uswsusp (it may or may not break hibernate). Since they've already done
that, and acknowledged the consequences, I'm sure Ubuntu will get little, if any bad press from this
group.

However, taking it from another perspective, pm-utils doesn't get fixed, and a group of very vocal
people who want to use uswsusp find out about the reason why it doesn't work on the hardy and solid
Ubuntu Hardy Heron. LTS, no less. I reckon that Ubuntu would (even more rightfully) get bad press.

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIv6nw4LFcUo8CpBERAiGKAJ9aIUuduT5Q7qOA+lhwg3L5szXbUgCgocvG
7EfCDUp8nwuF8myqeiJnIks=
=+s8A
-----END PGP SIGNATURE-----

[Chow Loong Jin (hyperair)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just realized that it's not just s2disk affected, but s2ram and s2both as well. So I've created a
more up to date debdiff, and a corresponding build log, which I've attached.

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIv8HT4LFcUo8CpBERAluzAJ0Wh21HEXbAsKobPN6/RZ7XwtI/lQCeMQyJ
qQgpAziji6VCOjMfxWNnfoY=
=lojt
-----END PGP SIGNATURE-----

[Steve Langasek (vorlon)]

> If that's the case, are you saying that pm-utils should be left in its
> current, broken state? While uswsusp might break for people who already
> have installed it, mistakenly, there are cases where people cannot
> hibernate without using uswsusp (and hence applying some workaround
> listed above which may or may not break future upgrades).

Sorry, yes; I believe this is a case where the potential for regressions
outweighs the benefits of an SRU. I don't know of any recent hardware that
needs uswsusp to do suspend to disk or suspend to ram, but I do think
there's a risk that users who have uswsusp installed in hardy but don't need
it will see unfavorable behavior changes as a result of this non-standard
suspend mechanism.

So I think this bug is 'wontfix' for hardy.

What hardware do you have that doesn't work with the built-in suspend
support?

[Benoit Grégoire (benoitg)]

It was in the original bg report (I am the original reporter of this bug and solution), but somebody redacted it out. It's the Macbook pro core 2 duo. I think that more than qualifies as "Recent hardware" (not to mention pretty mainstream). Without this fix, it wont hibernate at all.

[Chow Loong Jin (hyperair)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We should also not forget that pm-utils's default hibernate takes a long time to suspend to disk and
to resume. s2disk is considerably faster at this. I've timed something like >60s time taken
consistently to resume, and s2disk taking ~20s. Even booting up is faster than waiting for
pm-utils's default suspend to disk to resume. This is undesirable, especially for people who need to
move from place to place frequently.

- --
Hyperair
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFI2GOK4LFcUo8CpBERAmcGAKCWrVRxOjMG6NCy3pKMi5LllJukHACeNj7m
7HkW/i2YdqmJTgOCrcDLzg8=
=XPFf
-----END PGP SIGNATURE-----