Comment # 66 on bug 925873 from Stefan Seyfried

(In reply to Thomas Blume from comment #34)

> 2. from there, mount your system root:
> 
> mount /dev/disk/by-uuid/4c63085f-b79c-427d-bd4f-46ad072de4af /sysroot

> You can then umount /sysroot and try to continue the resume by typing: exit.
> If this doesn't work, you need to reset your machine. 

This will possibly lead to data corruption. *NEVER EVER* touch any mounted file
system between suspend and resume.

If anything, mount an USB stick or a networked file system. Or a partition that
was not mounted in the suspended system (but I'd even avoid that).


(In reply to Stanislav Brabec from comment #40)
> Here are special features of other packages:

> suspend: suspend is capable to do encrypted hibernation. This feature is
> limited to computers with AT keyboard. USB keyboards are not supported for
> entering key passphrase.

...and this feature is not enabled in SUSE builds (it broke with newer
libgcrypt IIRC)

But suspend (s2disk) can do compressed multithreaded suspend which really
speeds up suspending and makes it possible to suspend bigger working sets to
smaller swap partitions.

s2disk can also suspend to a file instead of to a swap partition, I'm not sure
if in-kernel suspend can do that. I'm also not certain, that the wrappers in
opensuse support that feature at all.

It also can show a nice splash screen during suspend / resume with progress bar
etc., but this feature is also disabled in SUSE builds (it broke with splashy
and did not work nice with plymouth IIRC).

> pm-utils: This package contains special quirks for hibernation of some
> (mostly obsolete) devices: /usr/lib/pm-utils/sleep.d, and we have
> pm-utils-ndiswrapper.

pm-utils should die a horrible death :-)

> systemd also has a support for quirks in /usr/lib/systemd/system-sleep/ More
> than year ago, all package maintainers were asked to convert pm-utils quirks
> to systemd quirks.
> 
> Somebody also written a code to support pm-utils quirks inside systemd, but
> it seems to be dropped.
> 
> The status of pm-utils quirk database: Unmaintained for ~5 years.
> 
> Many quirks were working around ancient kernel or hardware bugs. Most of
> these bugs are already fixed, but quirks are staying.

That's why it needs to die :)

> Fedora has only systemctl, SLE12 has only systemctl as well.
> 
> 
> Here is my proposal:
> 
> 1. Drop "suspend" package now.

This will lose support for compressed suspend, but maybe someone will finally
put that feature into the kernel (where it would fit well).

So yes, dropping is probably a good idea.

> 2. Drop all binaries from pm-utils now, and add a systemd quirk calling
> pm-utils quirks. Rename the package to systemd-pm-utils-quirks, and remove
> this package from the all package selections. Over the time, port needed
> quirks to systemd, and drop the package later.

Needed quirks should be put into the kernel.

> 3. Add Obsoletes: suspend pm-utils to systemd package.
> 
> 4. Edit pm-utils-ndiswrapper accordingly (or drop)-

Drop :-)

(In reply to Takashi Iwai from comment #56)
> So, let me list and check each sleep.d hook:
> 
> 00logging:
> This one is obviously superfluous, we have other logging method.  Drop.

Yes.
All below is from my (sometimes flakey) memory, so to be used with a grain of
salt :-)

> 00powersave:
> The power-save is mostly irrelevant with sleep nowadays.  Drop.

The problem this solves is, that the kernel does / did not set e.g. settings
that were set before suspend (unplugging AC might have lowered display
brightness or sucht). calling "pm-powersave" would just do the same thing that
the desktop applet would have triggered when unplugging AC. Or that suspend was
on battery power, but resume on AC and the desktop applet would not notice the
"plug in" event.

The solution (probably already implemented since a long time) is to have the
desktop applets re-evaluate system state after resume and redo all the actions.

> 02rtcwake:
> This is an own RTC alarm setup.  Do we have an alternative in systemd or
> else?

This was a feature implemented by some novell person a few years ago for a
SLED11 feature request by some preload project IIRC.

> 06autofs:
> The autofs hook should be in systemd.  I thought we have some hook in
> NetworkManager, though.  Need to check.

Yes, belongs to Networkmanager or whatever.

> 30s2disk-check:
> This is likely superfluous.  A sanity check would be nice to have in
> systemd, too, but not mandatory.  If no enough page can be written, the
> hibernation aborts by itself.

oh, this does so much more! :-) But to be honest: if the user is stupid enough,
he can probably still do crazy things (see my comment on comment#34 of this
very bug :-), and a standard installation should not need this.

It also did autoconfigure s2disk, but if we are dropping "suspend" package and
support for userspace suspend, we don't need that anyway.

> 45pcmcia:
> This is superfluous.  The PCMCIA kernel subsystem itself supports PM.  Drop.

Well, and nobody has real PCMCIA anymore anyway.

> 70rcnetwork:
> Likely superfluous as 06autofs.  But need to check.

susi:~ # /etc/init.d/network stop-all-dhcp-clients
bash: /etc/init.d/network: No such file or directory

It cannot work :-)

> 75modules:
> This is an optional hook, and I guess some users have its own setup as a
> workaround.  Any systemd alternative?

Anyway, the kernel should be fixed instead.

> 90clock:
> This is also an optional hook.  This might be interesting to have in
> systemd, too.

no. comment in this hook:
# Modern kernels handle this correctly so we skip this hook by default.
Now this seems not to be true, because it is still running on my system, but we
should be able to do without.

> 94cpufreq:
> Drop.  It's a kernel's job, after all, and a regression should be reported
> to kernel.

Almost everything in there is the kernel's job. Working around in userspace
just makes those kernel developers lazy :-P

> 95led:
> This ACPI proc is obsoleted.  Drop.

Yes.

> 98video-quirk-db-handler:
> This one is the biggest one.  It's basically only for old non-KMS graphics. 
> If any, the hook and the existing video-quirks/* db can be in a package like
> pm-utils-legacy or such, as a possible rescue.

We can still try to reinstate something similar if we get reports of brokenness
after we dropped it :-)

> 99info:
> Drop, just an echo.
> 
> 99video:
> This is again for old systems, and can be possibly an opt-in together with
> 98video-quirk-db-handler.

interesting:
reset_brightness()
{
        for bl in /sys/class/backlight/* ; do
                [ -f "$bl/brightness" ] || continue
                BR="$(cat $bl/brightness)"
                echo 0 > "$bl/brightness"
                echo "$BR" > "$bl/brightness"
        done
}

If this is still necessary => kernel bug IMO.

> 99Zgrub:
> The same functionality should have been already in grub2 and/or systemd. 
> Drop (after fixing).

Yes. The idea was to *not* give the user the possibility to select anything in
GRUB during resume, to avoid stuff like comment#34 :-)

(In reply to Takashi Iwai from comment #61)
> (In reply to Cristian Rodr�guez from comment #60)
> > > 06autofs:
> > > The autofs hook should be in systemd.  I thought we have some hook in
> > > NetworkManager, though.  Need to check.
> > 
> > Isn't this an autofs bug ? if it needs to be restarted after resume or does
> > not respond.. maybe it misses an event ? a timer does not respond correctly
> > ? is it using CLOCK_MONOTONIC where it should be using CLOCK_BOOTTIME ? is
> > there a race condition ?
> 
> Well, we need to check what problem actually this has solved.  I vaguely
> remember autofs issue in 11.x time, but haven't tracked since then.

I think it solves the "network changed during suspend, the autofs config
(NIS/LDAP) changed, too, and autofs needs to know this" case.

> *We* as a distro need to provide a workaround until the kernel gets the fix.
> Sure, you can blame kernel, but it's no excuse to ignore the breakage.  Show
> must go on.  The system must keep working like before.
> 
> (And why systemd?  Because it ate others' cookies :)

yes, true.

(In reply to Dr. Werner Fink from comment #63)
> (In reply to Takashi Iwai from comment #61)
> > > > 90clock:
> This is not true for all use cases. If the kernel is in the eleven minutes
> mode then YES it is true (man:adjtimex(1)).  This is the normal case for
> most systems running the ntp service. Nevertheless if the hardware clock is
> out of sync and is to fast/slow then this is not true even with ntp as the
> kernel does not touch the hardware it the offset of its system clock and the
> BIOS hardware clock is equal of more then 15 minutes ->
> /usr/src/linux/kernel/time/ntp.c in ntp_validate_timex().

I think the suspend/resume case is different, but need to check the code to
confirm.