On 19 Apr 2016 04:53, "Andrei Borzenkov" <arvidj...@gmail.com> wrote: > > 19.04.2016 01:19, James Hogarth пишет: > > Hi all, > > > > There's been some discussion today about the impact of > > https://bugzilla.redhat.com/show_bug.cgi?id=1206936 and where the problem > > actually lies. > > > > The issue lies specifically with hibernate and affects all Fedora systems > > regardless of hardware (it's reproducible in a VM). > > > > The hibernate image gets written to swap correctly > > but hibernate-resume-generator.c looks specifically for 'resume' in > > /proc/cmdline to determine a) if any check shoudl even happen and b) which > > block device to check. > > > > When Fedora is installed anaconda does not write a resume= line > > to GRUB_CMDLINE_LINUX in /etc/default/grub or to the default kernel stanza > > for grubby to later duplicate. > > > > Dracut cmdline module does produce a resume= line but it appears this > > occurs too late for the generator to pick up. > > > > dracut cmdline is internal to dracut, so external programs do not see it. >
That would explain it, however it's somewhat confusing on the bug that dracut was pointed to as a place for a fix and the requests for dracut --print-cmdline if it had no affect. > > The end result is that without manual intervention to add an appropriate > > resume= line it's impossible to resume from hibernation on Fedora, and the > > critical battery behaviour (configured via /etc/Upower/Upower.conf and > > visible in upower -d) is to HybridSleep. > > > > Is it feasible for systemd to have the generator pick a swap image > > regardless of resume being present or not? If so the dracut cmdline coming > > later than the hibernate generator wouldn't be a problem. > > > > Well, TBH the simplest solution is really to add resume= to kernel > command line. Otherwise let dracut install own generator that does > exactly the same when resume= is missing as real kernel parameter. In > both cases I do not think it is something that needs to be implemented > in systemd. The generator and the actual resume is already in systemd and the anaconda folks on the bug did not think it should be with them and that adding resume= would not be the correct fix (of course that additionally has the issue if fixed there of the current broken installs and how anaconda only creates that file on install). Seeing as systemd decides the swap to hibernate to in the first place, can't the same logic be used to locate the swap to resume from?
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
