sys-power/pm-utils after last-riting

halcon · l33t Joined: 15 Dec 2019 Posts: 629

Hi

The last-riting of sys-power/pm-utils and sys-power/pm-quirks was announced.

"Replaced by elogind or systemd builtin functions". As I don't use neither elogind, nor systemd, and as pm-utils work fine on my laptop, I decided to keep pm-utils in my GitHub repositories (despite of one more ebuild of the last 1.4.1-r7 version exists in c2p-overlay).

How that turned out:

I successfully copied pm-utils/pm-quirks ebuilds and all other files from the main Gentoo tree to my overlay.

Then I saw that the pm-utils ebuild applies many patches, missing upstream; the upstream, indeed, looks abandoned.

I made a fork of the pm-utils GitHub mirror, applied all the missing patches and made it a new version (1.4.2) - mainly for git practicing purposes. I've been able to commit some patches with `git am --signoff` so that their authors are shown.

Trying to write the ebuild for this new version, I found that the source code that I forked on GitHub differs from the source code of the last release used in ::Gentoo. The main difference is that there is no configure script in my fork.

I found a solution: 'eautoreconf' from autotools.eclass.

Finally, the new version is successfully compiling and installing. I haven't yet had time to test how it works.

Please ping me if :

you are also a user of pm-utils and are interested in keeping it available for Gentoo;
you know other patches to apply to pm-utils;
you find some issues using my overlay / fork.

https://github.com/halcon74/halcon-overlay/blob/master/sys-power/pm-utils/pm-utils-9999.ebuild
https://github.com/halcon74/pm-utils/commits/pm-utils-1.4

LAST UPDATE

Included all the patches present in ::gentoo before last-riting in January 2021, non-specific Debian patches and a patch from c2p-overlay.
Included all the additional files from Gentoo/Debian (the same).
Deleted obsolete files which was being removed by Gentoo ebuild / Debian rules.
Included pm-quirks.
Fixed Gentoo bugs 666380, 579912, 549848, 489650, 443530, 703026 and Debian bugs 485443, 659260.
_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs.

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

You might also want to check if sys-power/suspend does what you need instead.

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2014

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

At least it seems to have regular snapshots:

halcon · l33t Joined: 15 Dec 2019 Posts: 629

asturm, Goverp, thanks for your attention!

patrickdepinguin · n00b Joined: 18 Jan 2007 Posts: 14

I have been using pm-utils for years without problems. Having seen the deprecation, I emerged sys-power/suspend to see if I can use that instead.

However, since I installed sys-power/suspend, my regular pm-hibernate is broken. It hibernates fine based on the logs, but the thaw does not happen and I get a full boot from scratch.

I have not made any changes to the configuration of pm-utils or kernel, I just installed sys-power/suspend. I don't understand the link between both.

I also tried running s2disk from sys-power/suspend, which first expected a valid config file. I made one change to the stock config file, to fill in my resume partition (set to my swap partition). This seems to resume but also does not thaw.

I would be fine with sys-power/suspend if it worked, or continue using a forked pm-utils. But like halcon, I don't want to install elogind just to get something to work that worked fine before without it.

Do you have any tips on restoring or debugging my current pm-utils setup?

And what are the remaining problems with your fork? You mention some problems with autotools but it's not clear to me what they currently are. I have some knowledge of autotools in general, not specifically inside ebuilds though.

Hu · Administrator Joined: 06 Mar 2007 Posts: 21724

You may need to use a matched suspend/resume pair. If you hibernate with s2disk, you need to resume using the resume command from the same package. If you hibernate using the in-kernel hibernation, then you need to use the in-kernel resume. Mixing may lead to the resume side logic failing to recognize a "foreign" hibernation image, which it would then refuse to resume. I used sys-power/suspend for a long time, but switched to the in-kernel hibernation and have been quite happy with it.

halcon · l33t Joined: 15 Dec 2019 Posts: 629

patrickdepinguin · n00b Joined: 18 Jan 2007 Posts: 14

I found the link between sys-power/suspend and pm-utils: pm-hibernate will actually hibernate via s2disk if that binary is found. So the installation of sys-power/suspend does change the behavior of pm-utils.
Uninstalling sys-power/suspend again fixes my hibernation via pm-utils.

I still don't understand the reason that s2disk did not work though. I looked at the scripts in the initramfs, and as far as I can see the resume part should be the same between the kernel hibernation and software hibernation via s2disk, i.e. echo'ing the resume device to a /sys file. So the problem may be in the hibernate part itself.

I do have an encrypted root partition with luks/dm-crypt, although my swap is unencrypted. On the following gentoo bug, there is a reference to requiring 'resume-offset' in such case, but it's not clear to me what the offset should be. And also, it's not clear whether or not this bug is still applicable, i.e. whether genkernel supports resume from s2disk out-of-the-box now or not.
https://bugs.gentoo.org/156445#c50

halcon · l33t Joined: 15 Dec 2019 Posts: 629

Hu · Administrator Joined: 06 Mar 2007 Posts: 21724

patrickdepinguin · n00b Joined: 18 Jan 2007 Posts: 14

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

patrickdepinguin · n00b Joined: 18 Jan 2007 Posts: 14

That wiki page says:

"The following software can be used for in-kernel default suspend/hibernate implementation, namely, swsusp.
root #emerge --ask sys-power/suspend"

My understanding is that 'swsusp' is indeed the kernel implementation, but this does _not_ need sys-power/suspend, which is specifically created for userspace-driver suspend/hibernate, called _uswsusp_.
So the above wiki statement seems incorrect to me, although I'm not fully sure.

Generally, if desiring to use the kernel method of resuming, by interacting with sysfs, it is not clear to me what any package like pm-utils or hibernate-script offers over directly writing to sysfs.

halcon · l33t Joined: 15 Dec 2019 Posts: 629

patrickdepinguin · n00b Joined: 18 Jan 2007 Posts: 14

I installed hibernate-script now, and tested both 'hibernate-ram' (suspend to memory) and 'hibernate' (suspend to disk).
It worked right out of the box without any changes, coming from using pm-suspend and pm-hibernate.
The script will try using the sys-power/suspend tools when present, and the tuxonice method in case you're running that kernel. As I have neither, it uses the same method as pm-hibernate was using, i.e. kernel swsusp via sysfs.

If I don't bump into new problems in the coming days, I'll remove pm-utils and consider hibernate-script as the new method.

halcon · l33t Joined: 15 Dec 2019 Posts: 629

...Found that sys-power/hibernate-script is written by Nigel Cunningham, the author of TuxOnIce. Very promising!

But only one file has been changed in its code for past 10 years...

_________________
A wife asks her husband, a programmer:
- Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6?
He comes back with 6 cartons of milk.
- Why did you buy 6 cartons of milk?
- They had eggs.

Hu · Administrator Joined: 06 Mar 2007 Posts: 21724

It is just a wrapper to invoke all the real actions in the right order. Once that order is found, it may not need further maintenance, since all the real work is done by the things it runs for you. The important question is not how much its code has changed, but how many open issues exist for it.

halcon · l33t Joined: 15 Dec 2019 Posts: 629

Ionen · Developer Joined: 06 Dec 2018 Posts: 2727

halcon · l33t Joined: 15 Dec 2019 Posts: 629

Ionen,

Thanks for clarification!

Goverp · Advocate Joined: 07 Mar 2007 Posts: 2014

FWIW: I replaced pm-utils with laptop-mode-tools. Works OK; haven't noticed any change in power consumption. It may be of interest to know it installs a simple Qt5 GUI and creates a desktop menu item. The GUI lets you switch off things that don't apply or seem desirable - there's hover-help to give a one-liner description of the various knobs to turn. AFAIR, it can exploit some other packages, notably hdparm and or sdparm; I've not tried it with them.
_________________
Greybeard

Princess Nell · l33t Joined: 15 Apr 2005 Posts: 916

Not having looked at the code - what is the specific autotools/automake problem you need to solve?

halcon · l33t Joined: 15 Dec 2019 Posts: 629

asturm · Developer Joined: 05 Apr 2007 Posts: 8938

Handmade build scripts are consistently the worst case scenario for packaging. Better keep autotools then.