http://bugzilla.opensuse.org/show_bug.cgi?id=904828 David Kerkhof <dutchkind@txoriaskea.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dutchkind@txoriaskea.org --- Comment #3 from David Kerkhof <dutchkind@txoriaskea.org> --- So how can we now run commands on suspend? I need to close an encrypted container before the system suspends -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904828 Guido Berhörster <gber@opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vdziewiecki@suse.com --- Comment #6 from Guido Berhörster <gber@opensuse.org> --- (In reply to David Kerkhof from comment #5)

Thanks, that helps. Would be nice to have read this change in the Release Notes.

Just to clarify since you seem to misunderstand the problem, this bug is not about that one mechanism was replaced by another but that there was no followup to the opensuse-factory@ discussion and the systemd package just dropped pm-utils support leading to silent failure not only of user scripts but also dependent packages. So what needs to be done in the long term is a followup to the discussion, addressing of the issues raised, assessment of the fixes delivered by pm-utils to avoid regressions, adaptation of any dependent packages to use systemd hooks instead, removal of pm-utils from patterns and finally removal of pm-utils from Factory. I was under the impression Vojtěch intended take care of that but it seems nothing has happened. In the short term there needs to be a fix for 13.2 and current Tumbleweed users, I was lucky enough to notice the constant head-parking and to remember the pm-utils discussion but you can't expect that from regular users who will likely not read the release notes. We could either re-enable the patch for pm-utils integration or drop a wrapper shell script into /usr/lib/systemd/system-sleep/ which calls /usr/lib/pm-utils/sleep.d with pm-utils semantics and takes /etc/pm/sleep.d into account and issue a maintenance update. I'd be willing to take care of that since I want this to be fixed ASAP. @Werner, Thomas Does that sound ok? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904828 --- Comment #22 from Wolfgang Bauer <wbauer@tmo.at> --- (In reply to Guido Berhörster from comment #20)

I've just created a new maintenancerequest backporting the workaround that reactivates the patch which calls pm-utils for suspend/hibernate (just as in 13.1), this should resolve the issue for 13.2.

Ok, but I still have one question regarding this update: At the moment, in 13.2 and Factory, systemd-hibernate.service (and systemd-hybrid-sleep.service) calls /usr/bin/systemd-sleep-grub before and after hibernation (independent of the hibernate/resume scripts). Will this still be called after the update? If yes, then again the same work will be done _twice_, by /usr/bin/systemd-sleep-grub _and_ by pm-utils' 99Zgrub script, probably leading to problems. In this case, 99Zgrub should probably be removed from pm-utils in the same update. If no, and only 99Zgrub is called, there's this bug: bug#856391 In short, grub2 is not able to reset the entry to boot on btrfs. The hibernate script sets this to prevent booting a different OS before the resume (dataloss) and should revert this to restore the boot menu on resume. But 99Zgrub has a bug which breaks this restoration, and as btrfs is the default filesystem in 13.2 we probably will get many complaints from users that "lost" their boot menu after hibernation. I have a fix for 99Zgrub, but we should release that one before (or at least together with) this update in that case IMHO. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904828 --- Comment #24 from Benjamin Brunner <bbrunner@suse.com> --- I'll combine the update as soon as there is a submission for pm-utils. Thanks for the clarifications! -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904828 --- Comment #26 from Wolfgang Bauer <wbauer@tmo.at> --- (In reply to Guido Berhörster from comment #25)

Wolfgang, will you take care of pushing that to Factory and sending a maintenancerequest?

I already created a SR for base:utils (devel project for Factory) earlier today: https://build.opensuse.org/request/show/263073 Submitted a maintenance request now as well: https://build.opensuse.org/request/show/263102 I included packages for 12.3 and 13.1 as well, I hope that's ok. It's not that critical there, as btrfs is not the default, but should be fixed too I think. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904828 --- Comment #28 from Wolfgang Bauer <wbauer@tmo.at> --- PS: I tried out that pending systemd update now. It does indeed use pm-utils again, but systemd-sleep-grub is still called as well (in addition to 99Zgrub). I see its output in the systemd journal. So the update doesn't completely revert the state to 13.1... As I already hinted at, systemd-sleep-grub is called by systemd-hibernate.service (and systemd-hybrid-sleep.service), via this lines: ExecStart=/usr/bin/systemd-sleep-grub pre ExecStart=/usr/lib/systemd/systemd-sleep hibernate ExecStopPost=/usr/bin/systemd-sleep-grub post But just removing it there is also no option I think, as it is needed when pm-utils is not installed. Hm. Maybe calling both doesn't pose a problem anyway? I hope so. At least I didn't see any problem right now. But I haven't tested with btrfs. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904828 --- Comment #31 from Wolfgang Bauer <wbauer@tmo.at> --- (In reply to Thomas Blume from comment #30)

See:

bug 856392 comment #18

for an explanation. Hm, I don't see any comment#18 there?

But apparently all scripts in there are called in parallel, I guess this is the reason, right? Then it's no good idea anyway, ignore my comment#29 then please. -- You are receiving this mail because: You are on the CC list for the bug.