On 19 Apr 2016 08:05, "Andrei Borzenkov" <<a href="mailto:arvidjaar@gmail.com">arvidjaar@gmail.com</a>> wrote: > > On Tue, Apr 19, 2016 at 9:45 AM, James Hogarth <<a href="mailto:james.hogarth@gmail.com">james.hogarth@gmail.com</a>> wrote: > > > > > Seeing as systemd decides the swap to hibernate to in the first place, can't > > No, it does not. Device to hibernate to is set by previous attempt to > resume from. This device must come from somewhere. Last device someone > attempted to resume from will be used in subsequent attempt to > hibernate. > > So I would definitely be against anyone blindly poking around at every > available partition because later kernel will overwrite content of > this partition when hibernation is requested. > I agree that would be messy. What about the first hibernation when no previous resume has occurred? > > the same logic be used to locate the swap to resume from? > > There is no logic here. User decides where to resume from and later > the same device is used to hibernate to. > > systemd already has all needed knobs to configure this. Is there any > reason you refuse to use these knobs? Well it has to pick something the first time. I would urge you to read the bug and the relevant blocker discussion notes. I've added resume= to my cmdline and am happy with that, however every Fedora user who is not specifically aware of the need to do that has a broken hibernate, with the upower configuration being to hybrid sleep (so effectively hibernate) when battery levels are critical. The "broken default application behaviour" could be "fixed" by changing upower to shutdown instead. The user would then be notified of the shutdown and not that hibernate would happen. This would satisfy the Fedora release criteria but would still leave a broken systemctl hibernate with an unintuitive fix. It would also mean the big "don't change this file" warning in Upower.conf would put people off enabling that behaviour, but to be honest is out of the scope of this issue. It could also be fixed by anaconda adding resume= to the grub configuration like it already has to for the root device. The anaconda developers have already pushed against this and it would only fix fresh installs anyway. Dracut thought they'd fix it in cmdline but of course that doesn't act in a way any others can tell the changes. This leaves systemd as the component that has generator and the actual code that loads the resume image info the kernel. Although I'm fine I'd like to see other Fedora users not have a broken behaviour on their systems. Given your insights it would be valuable if you, or another systemd dev, would comment on the bug with the problem of "fixing the generator" so we can work out where the correct fix lies and the appropriate maintenance team to fix it.