On Sat, 2016-09-24 at 10:10 -0600, jd1008 wrote:
On 09/24/2016 08:20 AM, Ranjan Maitra wrote:
On Sat, 24 Sep 2016 10:12:23 +0100 "Patrick O'Callaghan" pocallaghan@gmail.com wrote:
On Fri, 2016-09-23 at 18:23 -0600, jd1008 wrote:
On 09/22/2016 05:24 PM, Patrick O'Callaghan wrote:
I'm using kernel-4.6.6-300.fc24.x86_64 with the proprietary NVidia driver, plus daily updates from the stable repos. Hibernation used to work with previous kernels, but now regularly fails to wake up properly, i.e. on restarting I get the BIOS screen followed by the boot text console and select the first (newest) option as usual. So far so good. Then after a few seconds I see the BIOS again, repeat the selection, and get a full reboot.
Anyone else seeing this?
poc
I saw it once or twice. The reason was (in my case) that when I hibernated, I had USB devices hooked up. When I rebooted without plugginf in those devices, it behaved exactly as you describe.
That's not the case in my setup. All USB devices have remained plugged in between hibernation and awakening.
Same here. The problem is machine-dependent and afflicts newer machines more than the older ones, in my experience, perhaps because the former have been tested more (by all).
Best wishes, Ranjan
OK, one thing to check:
$ cat /etc/default/grub GRUB_TIMEOUT=300 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) video=1366x768 resume=/dev/disk/by-uuid/281d4971-32b6-47e0-96a2-9bdc998a9b1c" GRUB_DISABLE_RECOVERY="false"
Does yours have the line GRUB_CMDLINE_LINUX ?? The resume= setting is necessary to hibernate. Once you set up this file , you will need to run grub2-mkconfig -o /boot/grub2/grub.cfg
and reboot, and hibernate and reboot again.
P.S: you must reboot into same OS you hibernated.
I should perhaps have mentioned that hibernation was working (almost) perfectly up until a couple of kernel updates ago. I say "almost" because Bluetooth sometimes recovers and sometimes doesn't, but the same happens with suspend/resume so I don't think that's relevant.
I compared my current /etc/default/grub file with the oldest backup I have, dated some time in June, and they are identical. In any case, this is what's in it:
$ cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet resume=UUID=1431e6d2-531e-46cd-8633-1cf878c6b2a1" GRUB_DISABLE_RECOVERY="true"
I note that the last line has "true" instead of "false", so maybe it shouldn't have worked before and now is failing correctly ...
poc