Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-16 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Apr 15, 2015 at 08:55:06AM -0700, Andrew Lutomirski wrote:
  - pm-utils DONE
 
  retired in master
 
 Is that good enough?  Should systemd obsolete it, too?  I thought the
 whole point of this thread was that pm-utils was actively dangerous
 now, so shouldn't we actively remove it from users' systems?

I wasn't dangerous, just confusing and obsolete. You raise a good point.
Nevertheless, systemd does not provide command-line compatiblity to pm-utils,
so I don't think we can obsolete it. Someone might be using it in their scripts,
etc.

Zbyszek

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-16 Thread Reindl Harald



Am 16.04.2015 um 14:31 schrieb Zbigniew Jędrzejewski-Szmek:

On Wed, Apr 15, 2015 at 08:55:06AM -0700, Andrew Lutomirski wrote:

- pm-utils DONE


retired in master


Is that good enough?  Should systemd obsolete it, too?  I thought the
whole point of this thread was that pm-utils was actively dangerous
now, so shouldn't we actively remove it from users' systems?


I wasn't dangerous, just confusing and obsolete. You raise a good point.
Nevertheless, systemd does not provide command-line compatiblity to pm-utils,
so I don't think we can obsolete it. Someone might be using it in their scripts,
etc.


well, and that is bad

back in the good old days replacements typically where commandline 
compatible and worked as drop-in replacement, these days people all day 
long are bothered with the new shiny things need work left and right 
from everybody and often the improvements are not worth the time wasted 
by thousands of people




signature.asc
Description: OpenPGP digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-16 Thread drago01
On Thu, Apr 16, 2015 at 2:31 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Wed, Apr 15, 2015 at 08:55:06AM -0700, Andrew Lutomirski wrote:
  - pm-utils DONE
 
  retired in master

 Is that good enough?  Should systemd obsolete it, too?  I thought the
 whole point of this thread was that pm-utils was actively dangerous
 now, so shouldn't we actively remove it from users' systems?

 I wasn't dangerous, just confusing and obsolete. You raise a good point.
 Nevertheless, systemd does not provide command-line compatiblity to pm-utils,
 so I don't think we can obsolete it. Someone might be using it in their 
 scripts,
 etc.

Just replace it with wrapper scripts that use systemctl under the hood.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Apr 14, 2015 at 11:00:52AM -0400, Przemek Klosowski wrote:
 On 04/13/2015 11:34 PM, Zbigniew Jędrzejewski-Szmek wrote:
 OK, so swap 2x memory seems excessive. Actually swap with the same as
 memory should work *most* of the time. There's no guarantee that any
 amount swap will be enough, since it could all be filled by the time
 hibernation is requested, but we should try to cover most normal
 usage. But considering that swap will be slow on HDD, so users will
 most likely avoid using more than a small amount, and SDD are small,
 so it's expensive to provide bigger swap, the default that anaconda
 uses seems OK. An exception is for computers with small amount of RAM
 (= 2GB?). There swaps is more likely to be filled and the default
 size for swap should imho be higher than the amount of RAM.
 Exactly! remember that a typical disk speed is few tens of MB/s,
 i.e. about 1 GB/min. I came to the conclusion that anything more
 than 4GB is just counterproductive. Large swap just deceives us into
 thinking that we can run jobs larger than the physical memory but
 that is really not the case, just like Seymour Cray said [1].
The amount of swap space used should be controlled by vm.swappiness
sysctl and kernel algorithms, not by making the swap small.

 Maybe swap space should simply be max(4GB, $PhysicalMemory).
 Actually, isn't 'swap to filesystem' still an option? if so,  maybe
 swap should be a constant 4GB, and hibernation should create an
 appropriately sized file on the fly, join it to the swap and use
 both.
I think it should be other way around: swap partition big enough to
hibernate, i.e. the size of RAM, and a dynamnically sized swap
file if more swap space is needed for non-hibernation data.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Zbigniew Jędrzejewski-Szmek
On Tue, Apr 14, 2015 at 09:30:31AM -0600, Chris Murphy wrote:
 On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera bnoc...@redhat.com wrote:
 
 
  - Original Message -
  OK not everyone is on the same page, apparently. This bug was just
  closed by Anaconda as WONTFIX.
 
  suggested swap for laptop seems low
  https://bugzilla.redhat.com/show_bug.cgi?id=1037472
 
  I don't see how hibernation works reliably with such a low default swap 
  size.
 
  This isn't the way to fix it. The hibernation file/partition should really 
  be independent
  of swap, because 1) you can't be sure how much swap will actually be used 
  by the applications
  so you can't be sure you'll ever have enough swap to save the RAM 2) Too 
  much swap and the
  (lack of) interactivity will make you want to advocate physical violence 
  when your machine
  is unusable for an hour because of a hungry Javascript in your 50th Firefox 
  tab.
 
 Windows and OS X both use swapfiles rather than swap partition, and a
 sleep image file rather than a partition. OS X's swapfiles are
 dynamically created on demand in variable size increments.
I think the problem is in the ways filesystems are implemented.  The
fs has to be mounted to access the swap file, and this can change the
fs, even with a read-only mount. Because we don't have
really-read-only fs mounting, we need to support swap-as-partition, so
we might just as well use it by default.

 Both OS's have a feature that I find invaluable on a laptop which is
 the automatic switch from suspend-to-RAM to suspend-to-disk.
Yes, integrating with firmware would be great. So far this hasn't been 
hapenning...
What we can do instead is use hybrid sleep. It's not smart at all,
and doesn't prevent your battery from draining completely, but it does protect
your data.

Systemd supports hybrid-sleep as another option analogous to suspend
and hibernation, so for anything using systemd to suspend swithing to
hybrid should be trivial. Maybe we should make this an F23 goal:
- use hybrid-sleep from Gnome and other DE by default

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Bastien Nocera


- Original Message -
 On Wed, Apr 15, 2015 at 10:26:14AM -0400, Bastien Nocera wrote:
  
  
  - Original Message -
   On Tue, Apr 14, 2015 at 09:30:31AM -0600, Chris Murphy wrote:
On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera bnoc...@redhat.com
wrote:


 - Original Message -
 OK not everyone is on the same page, apparently. This bug was just
 closed by Anaconda as WONTFIX.

 suggested swap for laptop seems low
 https://bugzilla.redhat.com/show_bug.cgi?id=1037472

 I don't see how hibernation works reliably with such a low default
 swap
 size.

 This isn't the way to fix it. The hibernation file/partition should
 really be independent
 of swap, because 1) you can't be sure how much swap will actually be
 used
 by the applications
 so you can't be sure you'll ever have enough swap to save the RAM 2)
 Too
 much swap and the
 (lack of) interactivity will make you want to advocate physical
 violence
 when your machine
 is unusable for an hour because of a hungry Javascript in your 50th
 Firefox tab.

Windows and OS X both use swapfiles rather than swap partition, and a
sleep image file rather than a partition. OS X's swapfiles are
dynamically created on demand in variable size increments.
   I think the problem is in the ways filesystems are implemented.  The
   fs has to be mounted to access the swap file, and this can change the
   fs, even with a read-only mount. Because we don't have
   really-read-only fs mounting, we need to support swap-as-partition, so
   we might just as well use it by default.
   
Both OS's have a feature that I find invaluable on a laptop which is
the automatic switch from suspend-to-RAM to suspend-to-disk.
   Yes, integrating with firmware would be great. So far this hasn't been
   hapenning...
   What we can do instead is use hybrid sleep. It's not smart at all,
   and doesn't prevent your battery from draining completely, but it does
   protect
   your data.
   
   Systemd supports hybrid-sleep as another option analogous to suspend
   and hibernation, so for anything using systemd to suspend swithing to
   hybrid should be trivial. Maybe we should make this an F23 goal:
   - use hybrid-sleep from Gnome and other DE by default
  
  Hybrid sleep as offered in systemd still is just suspend + hibernation, and
  the way we do hibernation is broken.
 Can you be more specific? Do you consider hibernate-to-swap-partition
 unacceptable?

I think that conflating memory-to-disk swap space with I can hibernate my 
machine
is unacceptable. We need a new partition type that Anaconda would setup, or
a whitelist of laptops with firmwares that support rapid start (and again, 
Anaconda
to set it up), or use a temporary file of any sort to store the hibernation 
data.

If my machine has 8 gigs of memory, I don't want to need 8 gigs plus of swap to 
be
able to hibernate it, when run away processes can make my machine unusable for 
hours
if they start hitting that swap.

  Hybrid sleep is already the default on low battery with newer versions of
  UPower.
 Yeah, I wasn't aware of that. This should be a good thing.
 
 Zbyszek
  
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Przemek Klosowski

On 04/15/2015 09:07 AM, Zbigniew Jędrzejewski-Szmek wrote:

Maybe swap space should simply be max(4GB, $PhysicalMemory).
Actually, isn't 'swap to filesystem' still an option? if so,  maybe
swap should be a constant 4GB, and hibernation should create an
appropriately sized file on the fly, join it to the swap and use
both.

I think it should be other way around: swap partition big enough to
hibernate, i.e. the size of RAM, and a dynamnically sized swap
file if more swap space is needed for non-hibernation data.



You're right, that seems like a cool way to do it---a sparse 
/thin-provisioned file that's recreated on every boot.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Przemek Klosowski

On 04/15/2015 11:02 AM, Bastien Nocera wrote:
I think that conflating memory-to-disk swap space with I can 
hibernate my machine is unacceptable. We need a new partition type 
that Anaconda would setup, or a whitelist of laptops with firmwares 
that support rapid start (and again, Anaconda to set it up), or use a 
temporary file of any sort to store the hibernation data. If my 
machine has 8 gigs of memory, I don't want to need 8 gigs plus of swap 
to be able to hibernate it, when run away processes can make my 
machine unusable for hours if they start hitting that swap.
Elsewhere in this thread Zbyszek suggested a RAM-sized swap partition 
for hibernation, plus a filesystem-resident swap file that grows as 
needed. If such file could be recreated as a sparse / thin-provisioned 
object on boot it would be pretty slick.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Apr 15, 2015 at 10:26:14AM -0400, Bastien Nocera wrote:
 
 
 - Original Message -
  On Tue, Apr 14, 2015 at 09:30:31AM -0600, Chris Murphy wrote:
   On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera bnoc...@redhat.com 
   wrote:
   
   
- Original Message -
OK not everyone is on the same page, apparently. This bug was just
closed by Anaconda as WONTFIX.
   
suggested swap for laptop seems low
https://bugzilla.redhat.com/show_bug.cgi?id=1037472
   
I don't see how hibernation works reliably with such a low default swap
size.
   
This isn't the way to fix it. The hibernation file/partition should
really be independent
of swap, because 1) you can't be sure how much swap will actually be 
used
by the applications
so you can't be sure you'll ever have enough swap to save the RAM 2) Too
much swap and the
(lack of) interactivity will make you want to advocate physical violence
when your machine
is unusable for an hour because of a hungry Javascript in your 50th
Firefox tab.
   
   Windows and OS X both use swapfiles rather than swap partition, and a
   sleep image file rather than a partition. OS X's swapfiles are
   dynamically created on demand in variable size increments.
  I think the problem is in the ways filesystems are implemented.  The
  fs has to be mounted to access the swap file, and this can change the
  fs, even with a read-only mount. Because we don't have
  really-read-only fs mounting, we need to support swap-as-partition, so
  we might just as well use it by default.
  
   Both OS's have a feature that I find invaluable on a laptop which is
   the automatic switch from suspend-to-RAM to suspend-to-disk.
  Yes, integrating with firmware would be great. So far this hasn't been
  hapenning...
  What we can do instead is use hybrid sleep. It's not smart at all,
  and doesn't prevent your battery from draining completely, but it does
  protect
  your data.
  
  Systemd supports hybrid-sleep as another option analogous to suspend
  and hibernation, so for anything using systemd to suspend swithing to
  hybrid should be trivial. Maybe we should make this an F23 goal:
  - use hybrid-sleep from Gnome and other DE by default
 
 Hybrid sleep as offered in systemd still is just suspend + hibernation, and
 the way we do hibernation is broken.
Can you be more specific? Do you consider hibernate-to-swap-partition 
unacceptable?

 Hybrid sleep is already the default on low battery with newer versions of 
 UPower.
Yeah, I wasn't aware of that. This should be a good thing.

Zbyszek
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Bastien Nocera


- Original Message -
 On Tue, Apr 14, 2015 at 09:30:31AM -0600, Chris Murphy wrote:
  On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera bnoc...@redhat.com wrote:
  
  
   - Original Message -
   OK not everyone is on the same page, apparently. This bug was just
   closed by Anaconda as WONTFIX.
  
   suggested swap for laptop seems low
   https://bugzilla.redhat.com/show_bug.cgi?id=1037472
  
   I don't see how hibernation works reliably with such a low default swap
   size.
  
   This isn't the way to fix it. The hibernation file/partition should
   really be independent
   of swap, because 1) you can't be sure how much swap will actually be used
   by the applications
   so you can't be sure you'll ever have enough swap to save the RAM 2) Too
   much swap and the
   (lack of) interactivity will make you want to advocate physical violence
   when your machine
   is unusable for an hour because of a hungry Javascript in your 50th
   Firefox tab.
  
  Windows and OS X both use swapfiles rather than swap partition, and a
  sleep image file rather than a partition. OS X's swapfiles are
  dynamically created on demand in variable size increments.
 I think the problem is in the ways filesystems are implemented.  The
 fs has to be mounted to access the swap file, and this can change the
 fs, even with a read-only mount. Because we don't have
 really-read-only fs mounting, we need to support swap-as-partition, so
 we might just as well use it by default.
 
  Both OS's have a feature that I find invaluable on a laptop which is
  the automatic switch from suspend-to-RAM to suspend-to-disk.
 Yes, integrating with firmware would be great. So far this hasn't been
 hapenning...
 What we can do instead is use hybrid sleep. It's not smart at all,
 and doesn't prevent your battery from draining completely, but it does
 protect
 your data.
 
 Systemd supports hybrid-sleep as another option analogous to suspend
 and hibernation, so for anything using systemd to suspend swithing to
 hybrid should be trivial. Maybe we should make this an F23 goal:
 - use hybrid-sleep from Gnome and other DE by default

Hybrid sleep as offered in systemd still is just suspend + hibernation, and
the way we do hibernation is broken.

Hybrid sleep is already the default on low battery with newer versions of 
UPower.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Andrew Lutomirski
On Mon, Apr 13, 2015 at 3:09 AM, Jaroslav Skarvada jskar...@redhat.com wrote:


 - Original Message -
 On 01.04.2015 10:29, Jaroslav Skarvada wrote:
  pm-hibernate is obsolete as others already mentioned.
 
  Do the pm-utils maintainers/upstream know this?
 
 
  Hi,
 
  I am pm-utils maintainer. I own some other legacy packages and
  I am retiring them only if there are good reasons for it
  (e.g. unfixed security bugs, breakage, etc.), because there may
  be still users using such packages / depending on their functionality.
 
  Regarding pm-utils, most of the functionality is currently handled
  by systemd. If there is anybody still using it, I think it shouldn't be
  hard to migrate. Also I think this package may be quite confusing
  for newcomers. Upstream said it's dead, so there are probably
  good reasons to retire. But currently there are the following
  packages in rawhide depending on pm-utils:
 
  cdm
  kdebase3


 Same as with the 'cdm'.

 http://pkgs.fedoraproject.org/cgit/kdebase3.git/commit/?id=2221c4
 +
 kdebase3.spec
 Patch26: kdebase-3.5.5-suspend.patch
 %define _with_suspend 1
 %{?_with_suspend:%patch26 -p1 -b .suspend}

 ---
  kdebase-3.5.5-suspend.patch | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/kdebase-3.5.5-suspend.patch b/kdebase-3.5.5-suspend.patch
 index 0462543..e1a5d0a 100644
 --- a/kdebase-3.5.5-suspend.patch
 +++ b/kdebase-3.5.5-suspend.patch
 @@ -62,8 +62,8 @@
  +void KSMShutdownDlg::slotSuspend()
  +{
  +switch ( suspendType ) {
 -+   case SUSPEND_TYPE_HIBERNATE: system(/usr/bin/pm-hibernate); break;
 -+   case SUSPEND_TYPE_STANDBY: system(/usr/bin/pm-suspend); break;
 ++   case SUSPEND_TYPE_HIBERNATE: system(/usr/bin/systemctl hibernate);
 break;
 ++   case SUSPEND_TYPE_STANDBY: system(/usr/bin/systemctl suspend);
 break;
  +}
  +reject();
  +}

 ...

  I will drop pm-utils when resolved
 
  regards
 
  Jaroslav
 

 And that's it.
 - cdm DONE
 - kdebase3 DONE
 - wicd DONE
 - pm-utils DONE




 Thanks,

 retired in master

Is that good enough?  Should systemd obsolete it, too?  I thought the
whole point of this thread was that pm-utils was actively dangerous
now, so shouldn't we actively remove it from users' systems?

--Andy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Chris Murphy
On Wed, Apr 15, 2015 at 7:03 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:

 I think the problem is in the ways filesystems are implemented.  The
 fs has to be mounted to access the swap file, and this can change the
 fs, even with a read-only mount.

At least on Linux I'm pretty sure the way swapfile works is it only
asks the fs at mkswap time what the contiguous blocks are for that
file. From that point on swapping to the swap file directly accesses
those blocks, not via the fs. And that's why swapfiles don't work with
either LVM thinp LVs or Btrfs or NFS since there's zero assurance the
swapfile will be where it was at mkswap time, let alone contiguous.
There's an NFS related patch to make this work that the Btrfs folks
were going to leverage, which I think works now as long as no
snapshots of the fs tree the swapfile is in are made. As soon as
there's a snapshot, both the original and the snapshot become subject
to COW.


 Both OS's have a feature that I find invaluable on a laptop which is
 the automatic switch from suspend-to-RAM to suspend-to-disk.
 Yes, integrating with firmware would be great. So far this hasn't been 
 hapenning...
 What we can do instead is use hybrid sleep. It's not smart at all,
 and doesn't prevent your battery from draining completely, but it does protect
 your data.

Great. I assume though that this requires some minimum swap
(partition) size though? So the installer bug needs to be reopened,
and set it to depend on kernel hibernation working correctly.

-- 
Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Chris Murphy
On Wed, Apr 15, 2015 at 9:02 AM, Bastien Nocera bnoc...@redhat.com wrote:


 - Original Message -
 On Wed, Apr 15, 2015 at 10:26:14AM -0400, Bastien Nocera wrote:
 
 
  - Original Message -
   On Tue, Apr 14, 2015 at 09:30:31AM -0600, Chris Murphy wrote:
On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera bnoc...@redhat.com
wrote:


 - Original Message -
 OK not everyone is on the same page, apparently. This bug was just
 closed by Anaconda as WONTFIX.

 suggested swap for laptop seems low
 https://bugzilla.redhat.com/show_bug.cgi?id=1037472

 I don't see how hibernation works reliably with such a low default
 swap
 size.

 This isn't the way to fix it. The hibernation file/partition should
 really be independent
 of swap, because 1) you can't be sure how much swap will actually be
 used
 by the applications
 so you can't be sure you'll ever have enough swap to save the RAM 2)
 Too
 much swap and the
 (lack of) interactivity will make you want to advocate physical
 violence
 when your machine
 is unusable for an hour because of a hungry Javascript in your 50th
 Firefox tab.
   
Windows and OS X both use swapfiles rather than swap partition, and a
sleep image file rather than a partition. OS X's swapfiles are
dynamically created on demand in variable size increments.
   I think the problem is in the ways filesystems are implemented.  The
   fs has to be mounted to access the swap file, and this can change the
   fs, even with a read-only mount. Because we don't have
   really-read-only fs mounting, we need to support swap-as-partition, so
   we might just as well use it by default.
  
Both OS's have a feature that I find invaluable on a laptop which is
the automatic switch from suspend-to-RAM to suspend-to-disk.
   Yes, integrating with firmware would be great. So far this hasn't been
   hapenning...
   What we can do instead is use hybrid sleep. It's not smart at all,
   and doesn't prevent your battery from draining completely, but it does
   protect
   your data.
  
   Systemd supports hybrid-sleep as another option analogous to suspend
   and hibernation, so for anything using systemd to suspend swithing to
   hybrid should be trivial. Maybe we should make this an F23 goal:
   - use hybrid-sleep from Gnome and other DE by default
 
  Hybrid sleep as offered in systemd still is just suspend + hibernation, and
  the way we do hibernation is broken.
 Can you be more specific? Do you consider hibernate-to-swap-partition
 unacceptable?

 I think that conflating memory-to-disk swap space with I can hibernate my 
 machine
 is unacceptable. We need a new partition type that Anaconda would setup, or
 a whitelist of laptops with firmwares that support rapid start (and again, 
 Anaconda
 to set it up), or use a temporary file of any sort to store the hibernation 
 data.

I'm willing to bet there's an incongruence between IRST and multiboot.


 If my machine has 8 gigs of memory, I don't want to need 8 gigs plus of swap 
 to be
 able to hibernate it, when run away processes can make my machine unusable 
 for hours
 if they start hitting that swap.

Googling brings up the swapspace project for dynamically creating
swapfiles. However, for Btrfs and LVM thinp installs, I think the base
swap code needs revisiting to defer rw through the fs rather than
assuming direct rw is workable.

-- 
Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Bastien Nocera


- Original Message -
 On Tue, Apr 14, 2015 at 12:39:04AM +, Zbigniew Jędrzejewski-Szmek wrote:
 
  Yeah, hibernation is automatically invoked when battery runs low
 
 Is this actually the default behaviour?

We call either HybridSleep, Hibernate or PowerOff, depending on what the system
offers, and in that order:
http://cgit.freedesktop.org/upower/tree/src/linux/up-backend.c#n383
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-15 Thread Matthew Garrett
On Tue, Apr 14, 2015 at 12:39:04AM +, Zbigniew Jędrzejewski-Szmek wrote:

 Yeah, hibernation is automatically invoked when battery runs low

Is this actually the default behaviour?

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-14 Thread Bastien Nocera


- Original Message -
 OK not everyone is on the same page, apparently. This bug was just
 closed by Anaconda as WONTFIX.
 
 suggested swap for laptop seems low
 https://bugzilla.redhat.com/show_bug.cgi?id=1037472
 
 I don't see how hibernation works reliably with such a low default swap size.

This isn't the way to fix it. The hibernation file/partition should really be 
independent
of swap, because 1) you can't be sure how much swap will actually be used by 
the applications
so you can't be sure you'll ever have enough swap to save the RAM 2) Too much 
swap and the
(lack of) interactivity will make you want to advocate physical violence when 
your machine
is unusable for an hour because of a hungry Javascript in your 50th Firefox tab.

I requested a hibernation partition that wasn't a swap partition:
https://wiki.gnome.org/BastienNocera/KernelWishlist
but it was deemed unnecessary by kernel devs (or work-aroundable maybe):
http://thread.gmane.org/gmane.linux.kernel/1810083/focus=1813873

We need to fix the kernel first, then we can ask for support in Anaconda.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-14 Thread Przemek Klosowski

On 04/13/2015 11:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

OK, so swap 2x memory seems excessive. Actually swap with the same as
memory should work *most* of the time. There's no guarantee that any
amount swap will be enough, since it could all be filled by the time
hibernation is requested, but we should try to cover most normal
usage. But considering that swap will be slow on HDD, so users will
most likely avoid using more than a small amount, and SDD are small,
so it's expensive to provide bigger swap, the default that anaconda
uses seems OK. An exception is for computers with small amount of RAM
(= 2GB?). There swaps is more likely to be filled and the default
size for swap should imho be higher than the amount of RAM.
Exactly! remember that a typical disk speed is few tens of MB/s, i.e. 
about 1 GB/min. I came to the conclusion that anything more than 4GB is 
just counterproductive. Large swap just deceives us into thinking that 
we can run jobs larger than the physical memory but that is really not 
the case, just like Seymour Cray said [1].


Maybe swap space should simply be max(4GB, $PhysicalMemory). Actually, 
isn't 'swap to filesystem' still an option? if so,  maybe swap should be 
a constant 4GB, and hibernation should create an appropriately sized 
file on the fly, join it to the swap and use both.

The details can be worked out. But I don't understand the justification
for closing of the bug:

(In reply to David Lehman from comment #1)

Anaconda does not automatically configure systems for hibernation at this
time.

Hibernation is important for many use cases, including graphical
environments, and anaconda should support them.

Absolutely agree.

[1] http://hackersays.com/68b2b7
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-14 Thread Chris Murphy
On Tue, Apr 14, 2015 at 3:07 AM, Bastien Nocera bnoc...@redhat.com wrote:


 - Original Message -
 OK not everyone is on the same page, apparently. This bug was just
 closed by Anaconda as WONTFIX.

 suggested swap for laptop seems low
 https://bugzilla.redhat.com/show_bug.cgi?id=1037472

 I don't see how hibernation works reliably with such a low default swap size.

 This isn't the way to fix it. The hibernation file/partition should really be 
 independent
 of swap, because 1) you can't be sure how much swap will actually be used by 
 the applications
 so you can't be sure you'll ever have enough swap to save the RAM 2) Too much 
 swap and the
 (lack of) interactivity will make you want to advocate physical violence when 
 your machine
 is unusable for an hour because of a hungry Javascript in your 50th Firefox 
 tab.

Windows and OS X both use swapfiles rather than swap partition, and a
sleep image file rather than a partition. OS X's swapfiles are
dynamically created on demand in variable size increments.

Recently, Windows on UEFI systems with the proper hardware uses Intel
Rapid Start [1], which is firmware managed suspend-to-disk. It depends
on both a unique partition and SSD, and by default a shutdown uses
this. Cold boots are really fast, like ~1.5 seconds. Faster than
reboots.

Both OS's have a feature that I find invaluable on a laptop which is
the automatic switch from suspend-to-RAM to suspend-to-disk. Because
of this, I never do shutdowns. I can always rely on just closing the
laptop lid to get suspend-to-RAM and if necessary (time or low
battery) the system wakes and suspends-to-disk. I can't rely on
suspend-to-RAM on linux because I can't guarantee I'll remember to
wake it and do a proper shutdown before the battery dies.

I'd put suspend-to-disk in the same category as video problems. It's
yet another reason to just not fight things, give up, and use what
works which is either Windows or OS X, and put Linux in a VM. *shrug*


 I requested a hibernation partition that wasn't a swap partition:
 https://wiki.gnome.org/BastienNocera/KernelWishlist
 but it was deemed unnecessary by kernel devs (or work-aroundable maybe):
 http://thread.gmane.org/gmane.linux.kernel/1810083/focus=1813873

 We need to fix the kernel first, then we can ask for support in Anaconda.

If kernel developers don't see working suspend-to-disk to be
important, then in my view Linux on the desktop is just short of
pointless and is just treading water with the existing behavior. The
two other OS's simply do this way way better and more reliably to the
point it's bulletproof and completely trustworthy.

How is this working on Chromebooks?

[1] http://mjg59.dreamwidth.org/26022.html


-- 
Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-13 Thread Chris Murphy
OK not everyone is on the same page, apparently. This bug was just
closed by Anaconda as WONTFIX.

suggested swap for laptop seems low
https://bugzilla.redhat.com/show_bug.cgi?id=1037472

I don't see how hibernation works reliably with such a low default swap size.


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-13 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Apr 13, 2015 at 04:39:38PM -0600, Chris Murphy wrote:
 OK not everyone is on the same page, apparently. This bug was just
 closed by Anaconda as WONTFIX.
 
 suggested swap for laptop seems low
 https://bugzilla.redhat.com/show_bug.cgi?id=1037472
 
 I don't see how hibernation works reliably with such a low default swap size.
Yeah, hibernation is automatically invoked when battery runs low (and is 
generally
useful in other cases), so we should provide enough swap for it to work. With
moern disk sizes 4GB one way or the other is hardly noticable, so it doesn't
make sense to economize.

Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-13 Thread Adam Williamson
On Tue, 2015-04-14 at 00:39 +, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Apr 13, 2015 at 04:39:38PM -0600, Chris Murphy wrote:
  OK not everyone is on the same page, apparently. This bug was just
  closed by Anaconda as WONTFIX.
  
  suggested swap for laptop seems low
  https://bugzilla.redhat.com/show_bug.cgi?id=1037472
  
  I don't see how hibernation works reliably with such a low default 
  swap size.
 Yeah, hibernation is automatically invoked when battery runs low 
 (and is generally
 useful in other cases), so we should provide enough swap for it to 
 work. With
 moern disk sizes 4GB one way or the other is hardly noticable,

'Modern disk sizes' like the 128GB (that's GB, not GiB) that's 
standard on the basic XPS 13 developer edition model, fr'instance? 
http://www.dell.com/us/business/p/xps-13-linux/pd
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-13 Thread Zbigniew Jędrzejewski-Szmek
On Mon, Apr 13, 2015 at 07:20:46PM -0700, Adam Williamson wrote:
 On Tue, 2015-04-14 at 00:39 +, Zbigniew Jędrzejewski-Szmek wrote:
  On Mon, Apr 13, 2015 at 04:39:38PM -0600, Chris Murphy wrote:
   OK not everyone is on the same page, apparently. This bug was just
   closed by Anaconda as WONTFIX.
   
   suggested swap for laptop seems low
   https://bugzilla.redhat.com/show_bug.cgi?id=1037472
   
   I don't see how hibernation works reliably with such a low default 
   swap size.
  Yeah, hibernation is automatically invoked when battery runs low 
  (and is generally
  useful in other cases), so we should provide enough swap for it to 
  work. With
  moern disk sizes 4GB one way or the other is hardly noticable,
 
 'Modern disk sizes' like the 128GB (that's GB, not GiB) that's 
 standard on the basic XPS 13 developer edition model, fr'instance? 
 http://www.dell.com/us/business/p/xps-13-linux/pd
That one's tough. Disk is less than 15 times memory size (30 or 60 for
the higher end models).

OK, so swap 2x memory seems excessive. Actually swap with the same as
memory should work *most* of the time. There's no guarantee that any
amount swap will be enough, since it could all be filled by the time
hibernation is requested, but we should try to cover most normal
usage. But considering that swap will be slow on HDD, so users will
most likely avoid using more than a small amount, and SDD are small,
so it's expensive to provide bigger swap, the default that anaconda
uses seems OK. An exception is for computers with small amount of RAM
(= 2GB?). There swaps is more likely to be filled and the default
size for swap should imho be higher than the amount of RAM.

The details can be worked out. But I don't understand the justification
for closing of the bug:

(In reply to David Lehman from comment #1)
 Anaconda does not automatically configure systems for hibernation at this
 time.
Hibernation is important for many use cases, including graphical
environments, and anaconda should support them.


Zbyszek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-13 Thread Samuel Sieb

On 04/13/2015 08:34 PM, Zbigniew Jędrzejewski-Szmek wrote:

The details can be worked out. But I don't understand the justification
for closing of the bug:

(In reply to David Lehman from comment #1)

Anaconda does not automatically configure systems for hibernation at this
time.

Hibernation is important for many use cases, including graphical
environments, and anaconda should support them.


Especially since Gnome by default hibernates on low battery.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-13 Thread Jaroslav Skarvada


- Original Message -
 On 01.04.2015 10:29, Jaroslav Skarvada wrote:
  pm-hibernate is obsolete as others already mentioned.
 
  Do the pm-utils maintainers/upstream know this?
 
  
  Hi,
  
  I am pm-utils maintainer. I own some other legacy packages and
  I am retiring them only if there are good reasons for it
  (e.g. unfixed security bugs, breakage, etc.), because there may
  be still users using such packages / depending on their functionality.
  
  Regarding pm-utils, most of the functionality is currently handled
  by systemd. If there is anybody still using it, I think it shouldn't be
  hard to migrate. Also I think this package may be quite confusing
  for newcomers. Upstream said it's dead, so there are probably
  good reasons to retire. But currently there are the following
  packages in rawhide depending on pm-utils:
  
  cdm
  kdebase3
 
 
 Same as with the 'cdm'.
 
 http://pkgs.fedoraproject.org/cgit/kdebase3.git/commit/?id=2221c4
 +
 kdebase3.spec
 Patch26: kdebase-3.5.5-suspend.patch
 %define _with_suspend 1
 %{?_with_suspend:%patch26 -p1 -b .suspend}
 
 ---
  kdebase-3.5.5-suspend.patch | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/kdebase-3.5.5-suspend.patch b/kdebase-3.5.5-suspend.patch
 index 0462543..e1a5d0a 100644
 --- a/kdebase-3.5.5-suspend.patch
 +++ b/kdebase-3.5.5-suspend.patch
 @@ -62,8 +62,8 @@
  +void KSMShutdownDlg::slotSuspend()
  +{
  +switch ( suspendType ) {
 -+   case SUSPEND_TYPE_HIBERNATE: system(/usr/bin/pm-hibernate); break;
 -+   case SUSPEND_TYPE_STANDBY: system(/usr/bin/pm-suspend); break;
 ++   case SUSPEND_TYPE_HIBERNATE: system(/usr/bin/systemctl hibernate);
 break;
 ++   case SUSPEND_TYPE_STANDBY: system(/usr/bin/systemctl suspend);
 break;
  +}
  +reject();
  +}
 
 ...
 
  I will drop pm-utils when resolved
  
  regards
  
  Jaroslav
  
 
 And that's it.
 - cdm DONE
 - kdebase3 DONE
 - wicd DONE
 - pm-utils DONE
 
 
 

Thanks,

retired in master

regards

Jaroslav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-09 Thread David Cantrell
Fixed in rawhide now.

Thanks,

On Thu, Apr 09, 2015 at 10:36:50AM +0200, poma wrote:
 On 01.04.2015 10:29, Jaroslav Skarvada wrote:
  pm-hibernate is obsolete as others already mentioned.
 
  Do the pm-utils maintainers/upstream know this?
 
  
  Hi,
  
  I am pm-utils maintainer. I own some other legacy packages and
  I am retiring them only if there are good reasons for it
  (e.g. unfixed security bugs, breakage, etc.), because there may
  be still users using such packages / depending on their functionality.
  
  Regarding pm-utils, most of the functionality is currently handled
  by systemd. If there is anybody still using it, I think it shouldn't be
  hard to migrate. Also I think this package may be quite confusing
  for newcomers. Upstream said it's dead, so there are probably
  good reasons to retire. But currently there are the following
  packages in rawhide depending on pm-utils:
  
  cdm
  kdebase3
  wicd
  
 
 http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/view/head:/INSTALL#L13
   8. pm-utils (optional for suspend/resume integration)
 
 http://bazaar.launchpad.net/~wicd-devel/wicd/experimental/view/head:/setup.py#L130
 ('no-install-pmutils', None, 'do not install the pm-utils hooks'),
 
 
 diff --git a/wicd.spec b/wicd.spec
 index a5dcaf0..bc7afe6 100644
 --- a/wicd.spec
 +++ b/wicd.spec
 @@ -36,7 +36,6 @@ BuildRequires:   desktop-file-utils
  BuildRequires:   pkgconfig
  BuildRequires:   systemd-units
  
 -Requires:pm-utils = 1.2.4
  Requires:%{name}-common = %{version}-%{release}
  
  %description
 @@ -140,10 +139,10 @@ rm -f po/ast.po
  --share %{_datadir}/wicd \
  --etc %{_sysconfdir}/wicd \
  --bin %{_bindir} \
 ---pmutils %{_libdir}/pm-utils/sleep.d \
  --log %{_localstatedir}/log \
  --systemd %{_systemd_unitdir} \
 ---no-install-init
 +--no-install-init \
 +--no-install-pmutils
  %{__python} setup.py build
  %{__python} setup.py compile_translations
  
 @@ -214,7 +213,7 @@ gtk-update-icon-cache %{_datadir}/icons/hicolor 
 /dev/null || :
  
  %files
  %defattr(-,root,root,-)
 -%{_libdir}/pm-utils/sleep.d/55wicd
 +%{_datadir}/autostart/wicd-tray.desktop
  
  %files common -f %{name}.lang
  %defattr(-,root,root,-)
 
 
  I will drop pm-utils when resolved
  
  regards
  
  Jaroslav
  
 

-- 
David Cantrell dcantr...@redhat.com
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-01 Thread Jaroslav Skarvada
  pm-hibernate is obsolete as others already mentioned.
 
 Do the pm-utils maintainers/upstream know this?
 

Hi,

I am pm-utils maintainer. I own some other legacy packages and
I am retiring them only if there are good reasons for it
(e.g. unfixed security bugs, breakage, etc.), because there may
be still users using such packages / depending on their functionality.

Regarding pm-utils, most of the functionality is currently handled
by systemd. If there is anybody still using it, I think it shouldn't be
hard to migrate. Also I think this package may be quite confusing
for newcomers. Upstream said it's dead, so there are probably
good reasons to retire. But currently there are the following
packages in rawhide depending on pm-utils:

cdm
kdebase3
wicd

I will drop pm-utils when resolved

regards

Jaroslav
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-04-01 Thread Richard Z
On Mon, Mar 30, 2015 at 08:57:56AM +0200, Till Maas wrote:

 There the problem is, that dracut runs a fsck check before deciding
 whether to resume. This can result in a big file system corruption,
 since the kernel had a different idea of the file system state after
 resuming from hibernation that there really is. 

thanks for spotting that. I have seen the resulting fs corruption and 
was suspecting something like that but was unable to investigate the 
details.

Richard

---
Name and OpenPGP keys available from pgp key servers

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-31 Thread Zbigniew Jędrzejewski-Szmek
[cc maintainer]

On Mon, Mar 30, 2015 at 04:37:57PM +0100, Richard Hughes wrote:
 On 30 March 2015 at 15:42, drago01 drag...@gmail.com wrote:
  Can/should we just obsolete / retire it?
Agreed. It probably still has some uses, but it's just too
confusing to have it around.

Zbyszek

 
 I tried to, but I don't have enough super powers.
 
 Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-31 Thread Lennart Poettering
On Mon, 30.03.15 08:57, Till Maas (opensou...@till.name) wrote:

 Hi,
 
 it seems to be that me have a major problem of core package maintainers
 coordinating features in Fedora.
 
 See for example:
 https://bugzilla.redhat.com/show_bug.cgi?id=1174945
 
 There the problem is, that dracut runs a fsck check before deciding
 whether to resume. This can result in a big file system corruption,
 since the kernel had a different idea of the file system state after
 resuming from hibernation that there really is. The problem has several
 core players that do not seem to communicate:
 
 - dracut which uses systemd and showed this problem in F21 (I did not
   notice it in F20)
 - systemd:
 - might have changed things in F21 to break resuming
 - Does only parse the kernel command line, does not parse the
   options that dracut gathers from the system during initramfs
   generation
 - provides hibernation support via systemctl hibernate, which is
   also what pm-hibernate does (why do we have two tools for the same
   core task?)
 - anaconda, which does not add a resume= kernel command line option when
   installing a system
 
 Therefore please coordinate with others if you maintain a key component
 for a core distribution feature and look for other items that need to be
 adjusted.

systemd 217 introduced support for doing the hibernation resume logic
in the initrd on its own without any external support, see the man
page systemd-hibernate-resume(8). This does not require any explicit
support in Dracut.

pm-hibernate is obsolete as others already mentioned.

Lennart

-- 
Lennart Poettering, Red Hat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-31 Thread Till Maas
On Tue, Mar 31, 2015 at 07:40:58PM +0200, Lennart Poettering wrote:

 systemd 217 introduced support for doing the hibernation resume logic
 in the initrd on its own without any external support, see the man
 page systemd-hibernate-resume(8). This does not require any explicit
 support in Dracut.

What does this tell us? Fedora 21 uses systemd 216 according to the RPM
version. Does this already include all changes from 217? Why was a patch
for dracut necessary to get it work better? Is it supposed to run
without a resume= kernel parameter? If it needs one, then changes are
needed, because dracut stores the resume information in the initramfs
itself instead of using the kernel command line.

 pm-hibernate is obsolete as others already mentioned.

Do the pm-utils maintainers/upstream know this?

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Till Maas
Hi,

it seems to be that me have a major problem of core package maintainers
coordinating features in Fedora.

See for example:
https://bugzilla.redhat.com/show_bug.cgi?id=1174945

There the problem is, that dracut runs a fsck check before deciding
whether to resume. This can result in a big file system corruption,
since the kernel had a different idea of the file system state after
resuming from hibernation that there really is. The problem has several
core players that do not seem to communicate:

- dracut which uses systemd and showed this problem in F21 (I did not
  notice it in F20)
- systemd:
- might have changed things in F21 to break resuming
- Does only parse the kernel command line, does not parse the
  options that dracut gathers from the system during initramfs
  generation
- provides hibernation support via systemctl hibernate, which is
  also what pm-hibernate does (why do we have two tools for the same
  core task?)
- anaconda, which does not add a resume= kernel command line option when
  installing a system

Therefore please coordinate with others if you maintain a key component
for a core distribution feature and look for other items that need to be
adjusted.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Richard Hughes
On 30 March 2015 at 07:57, Till Maas opensou...@till.name wrote:
 - provides hibernation support via systemctl hibernate, which is
   also what pm-hibernate does (why do we have two tools for the same
   core task?)

pm-hibernate should have been removed from Fedora a long time ago. I
don't know what drags pm-utils onto the default install but it should
have died years ago.

Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Kalev Lember
On 03/30/2015 11:08 AM, Richard Hughes wrote:
 On 30 March 2015 at 07:57, Till Maas opensou...@till.name wrote:
 - provides hibernation support via systemctl hibernate, which is
   also what pm-hibernate does (why do we have two tools for the same
   core task?)
 
 pm-hibernate should have been removed from Fedora a long time ago. I
 don't know what drags pm-utils onto the default install but it should
 have died years ago.

And it's now gone from Workstation:

https://git.fedorahosted.org/cgit/comps.git/commit/?id=b8a057a7d8a3a77f7b657bf9e3620d1682d104e9

-- 
Kalev
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread drago01
On Mon, Mar 30, 2015 at 11:24 AM, Kalev Lember kalevlem...@gmail.com wrote:
 On 03/30/2015 11:08 AM, Richard Hughes wrote:
 On 30 March 2015 at 07:57, Till Maas opensou...@till.name wrote:
 - provides hibernation support via systemctl hibernate, which is
   also what pm-hibernate does (why do we have two tools for the same
   core task?)

 pm-hibernate should have been removed from Fedora a long time ago. I
 don't know what drags pm-utils onto the default install but it should
 have died years ago.

 And it's now gone from Workstation:

 https://git.fedorahosted.org/cgit/comps.git/commit/?id=b8a057a7d8a3a77f7b657bf9e3620d1682d104e9


Can/should we just obsolete / retire it?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Vít Ondruch
Luckily, resume from hybernation does not work at all for me on Rawhide:

https://bugzilla.redhat.com/show_bug.cgi?id=1199708


Vít



Dne 30.3.2015 v 08:57 Till Maas napsal(a):
 Hi,

 it seems to be that me have a major problem of core package maintainers
 coordinating features in Fedora.

 See for example:
 https://bugzilla.redhat.com/show_bug.cgi?id=1174945

 There the problem is, that dracut runs a fsck check before deciding
 whether to resume. This can result in a big file system corruption,
 since the kernel had a different idea of the file system state after
 resuming from hibernation that there really is. The problem has several
 core players that do not seem to communicate:

 - dracut which uses systemd and showed this problem in F21 (I did not
   notice it in F20)
 - systemd:
 - might have changed things in F21 to break resuming
 - Does only parse the kernel command line, does not parse the
   options that dracut gathers from the system during initramfs
   generation
 - provides hibernation support via systemctl hibernate, which is
   also what pm-hibernate does (why do we have two tools for the same
   core task?)
 - anaconda, which does not add a resume= kernel command line option when
   installing a system

 Therefore please coordinate with others if you maintain a key component
 for a core distribution feature and look for other items that need to be
 adjusted.

 Regards
 Till

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Richard Hughes
On 30 March 2015 at 11:21, Dominik 'Rathann' Mierzejewski
domi...@greysector.net wrote:
 Is systemctl hibernate/suspend the official replacement for
 pm-hibernate/suspend now?

Very much so :)

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Dominik 'Rathann' Mierzejewski
On Monday, 30 March 2015 at 11:08, Richard Hughes wrote:
 On 30 March 2015 at 07:57, Till Maas opensou...@till.name wrote:
  - provides hibernation support via systemctl hibernate, which is
also what pm-hibernate does (why do we have two tools for the same
core task?)
 
 pm-hibernate should have been removed from Fedora a long time ago. I
 don't know what drags pm-utils onto the default install but it should
 have died years ago.

Is systemctl hibernate/suspend the official replacement for
pm-hibernate/suspend now?

Regards,
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: hibernation support - lack of distro-wide coordination between systemd, dracut, anaconda, pm-utils and maybe more?

2015-03-30 Thread Richard Hughes
On 30 March 2015 at 15:42, drago01 drag...@gmail.com wrote:
 Can/should we just obsolete / retire it?

I tried to, but I don't have enough super powers.

Richard.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct