On Tue, December 30, 2014 3:25 am, David Brodie wrote: > On 28/12/14 16:13, Bruce Dubbs wrote: > >> On Sun, Dec 28, 2014 at 1:35 AM, Christopher Gregory >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> >> >> The issue is that systemd, and I strongly suspect the same is the >> case for pm-utils as well, although I can not find an exact answer for >> that tool, uses the kernel's native swsusp for handling >> suspend/hibernate/resume. >> >> This native kernel code, in order to be able to resume from a >> laptop/desktop being suspended to disk, which means that after you issue >> the pm-hibernate command in the case of pm-utils, this actually copies >> the entire contents of ram to your swap partition and then totally powers >> off your computer. The next time you restart your computer it is >> *meant* to >> resume from where you left off after going through the boot-up rotine. >> >> This does not happen unless you use an initramfs. It just plain >> ignores the saved suspended image and does a new boot instead. >> >> >> âIt does not do this for me. I have: >> >> âmenuentry 'LFS (SVN-20140604 on /dev/sda10 hibernate)' { linux >> /vmlinuz-3.14.3-lfs20140604 root=/dev/sda10 ro resume=/dev/sda11 >> } >> >> >> and hibernate works for me. At least it did when I last tried it from >> xfce. As you know, I'm not using systemd, but I am using a standard pci >> based disk drive, so I suspect something about that is causing the >> problem. > > Non-systemd, but works for me as well, albeit with vbetools and a sleep > hook for XScreensaver, and Nouveau crashing from time to time. :( > > With or without an initramfs - I use the latter to pre-load monitor EDID > data, if I'm using a cable splitter. > > David
Hello David, Thanks for the feedback on this. I am now in the process of building a systemV system to see if it works for me on there. I want to eliminate the possibility of some weird hardware quirk on my laptop. If I can pin point exactly what causes the failure, and if I can re-produce that failure over a number of builds then it will probably save others who are using systemd a few headaches along the way. I just do not like finding something that does not work the way it is meant to work. For all I know, it could be a change in the kernel code for 32 bit systems that is the issue. If it still does not work correctly after doing minimal work, then I will see about reverting to an earlier kernel, or even trying the exact version of build that Bruce has working. As stated, this is the first time that I have really tested it. When I tested the needed patches for xfce, if I recall correctly, I noticed then that it powered off the machine, and did not restore on restart but I just put that down to not having the resume= partition set on the kernel command line, even though I had the resume partition correctly set in the kernel before I compiled it. From reading, though not yet tested by me, you do not need the resume= if you have hard coded your resume partition in the kernel. It seems like this is going to be a rather long process of elimination. Like Ken does, I want to actually know what package to blame for this. Regards, Christopher. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
