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
On Fri, 23 Sep 2016 00:24:21 +0100 "Patrick O'Callaghan" pocallaghan@gmail.com 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?
I have been seeing this once in a while over the past two weeks. (And I do not have a NVidia card or driver.) However, in my case, it just reboots.
Initially, I thought that maybe I had run out of battery (even though this did not make sense), but the day before (when it last happened), I noticed that the battery was at 100% when it booted in. So, I had the same thought, and have been thinking of moving to the vanilla kernel (where hibernate works out of the box) since Fedora has decided that they and not the user should decide that we should not have support for hibernation (a decision which I am very disappointed with -- per reasoning below).
This decision has the potential to essentially kill hibernation in the long-term because fewer people will use it if something requires additional work to get it going (as happens with Fedora and I think Ubuntu). As a result, less people will be catching bugs and even fewer will be reporting them (of course, reporting within Fedora may not even be allowed anymore since it is disabled by default).
Hibernation besides, being environmentally friendly, also is often, when you are taking a long trip in the middle of nowhere, the only way to get your battery to last while working.
Anyway, sorry for expressing my disappointment.
Best wishes, Ranjan
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
On Thu, Sep 22, 2016 at 6:00 PM, Ranjan Maitra maitra.mbox.ignored@inbox.com wrote:
On Fri, 23 Sep 2016 00:24:21 +0100 "Patrick O'Callaghan" pocallaghan@gmail.com 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?
I have been seeing this once in a while over the past two weeks. (And I do not have a NVidia card or driver.) However, in my case, it just reboots.
Initially, I thought that maybe I had run out of battery (even though this did not make sense), but the day before (when it last happened), I noticed that the battery was at 100% when it booted in. So, I had the same thought, and have been thinking of moving to the vanilla kernel (where hibernate works out of the box) since Fedora has decided that they and not the user should decide that we should not have support for hibernation (a decision which I am very disappointed with -- per reasoning below).
This decision has the potential to essentially kill hibernation in the long-term because fewer people will use it if something requires additional work to get it going (as happens with Fedora and I think Ubuntu). As a result, less people will be catching bugs and even fewer will be reporting them (of course, reporting within Fedora may not even be allowed anymore since it is disabled by default).
Hibernation besides, being environmentally friendly, also is often, when you are taking a long trip in the middle of nowhere, the only way to get your battery to last while working.
Anyway, sorry for expressing my disappointment.
Part of the problem it Linux has to implement its own hibernation because Intel, one way or another, doesn't provide access to the various power states supported by the hardware. Like in the case of Rapid Start, which appeared to be supported in Windows 8 and is now dead (didn't last long) was something the vendor had to license to get access to the code. I have no idea what they're using now on Windows 10. So the hardware keeps changing. On the one hand the power management stuff in hardware is getting better but the required code isn't going into the kernel. That's just one part where it can fail.
Another part where it can fail now is UEFI Secure Boot. The image file isn't encrypted so it's possible to modify the image and bypass the whole point of Secure Boot. They're are patches but as far as I know they're not upstream. In fact Fedoras UEFI Secure Boot support isn't upstream because they've been dragging their feet on a distro unified position how to support it. That's another part where it won't work, yet anyway.
Next, there's disagreement between systemd, dracut, and anaconda developers on how to provide the hint to the kernel needed for it to find the hibernation image. All the other distros I'm familiar with use resume=<dev> as a boot parameter to do this, but anaconda devs say this is dracut's job to find it. So out of the box it's not even configured for hibernation.
Because of how hibernation works on Linux: the hibernation image is written to disk, then the computer is powered off, to resume you are actually cold booting, going through the bootloader which loads the kernel and initramfs just like a regular boot, but then the kernel sees the hint finds the hibernation image and loads it, it's actually pretty damn slow. If you have a pile of applications and docs open, yes all of that gets resumed as well with resume from hibernation, but not so for a true reboot. So there might still be some savings.
But even if everything none of the above apply, and you've configured it yourself, it can still fail just because of kernel and hardware bugs. I've tried using hibernation, the kernel finds the image, but then rejects it as bad, 100% of the time. So enabling this by default for everyone with no means of per model or per configuration blacklisting is fraught with peril. It's not appropriate to give people the idea their computer will safely hibernate, protecting their data, and then just face plant on resume.
I have no insight what the desktop folks are looking to build, but my take is that more applications need to save their states automatically. If they get force quit, such as what'd happen during an abrupt power off at critical power, they'd see this "dirty" state and recover on their own. Maybe there's something the DE could do to make that easier for developers to opt into. The idea of manually saving documents is pretty antiquated, we don't do this with mobile devices, there's no good reason why we're still doing this on laptops except it just hasn't caught up. The DE could maybe keep track of what programs are running, and again if upon login finds a "dirty" flag it can autolaunch those programs.
Anyway between, hardware, firmware, bootloader, kernel, installer, systemd, it's not easy for users to even produce quality bug reports that isolate the actual cause of hibernation not working. "not working" doesn't come close to helping pinpoint the problem. And long term I'm not sure either users or developers have much interest in this working any better than it does, or finding a better way entirely to do it seeing as we just aren't getting enough support from Intel for these sorts of things (or anyone else for that matter).
Example of how complicated and disappointing the problem is.
Hi listers I also noticed that hibernation in Fedora 24 does not work much more than in previous versions of fedora. I use hibernation because I want to be able to boot from the other disk on the PC next time I power it on, and this is not possible when using suspend. I have been using the resume=UUID=abcdefgh kernel parameter since fedora 12. Here, hibernation usually fails when going down, that is, the PC goes down but does not power off. So, I have to fully reboot (with file system check included) and try hibernation again. This usually happens when you are in a hurry...
I am very unhappy with the present situation.
suomi
On 09/23/2016 06:52 AM, Chris Murphy wrote:
Example of how complicated and disappointing the problem is.
https://mjg59.dreamwidth.org/41713.html?thread=1716465 _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org
On Thu, 2016-09-22 at 22:29 -0600, Chris Murphy wrote:
On Thu, Sep 22, 2016 at 6:00 PM, Ranjan Maitra maitra.mbox.ignored@inbox.com wrote:
On Fri, 23 Sep 2016 00:24:21 +0100 "Patrick O'Callaghan" pocallaghan@gmail.com 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?
I have been seeing this once in a while over the past two weeks. (And I do not have a NVidia card or driver.) However, in my case, it just reboots.
Initially, I thought that maybe I had run out of battery (even though this did not make sense), but the day before (when it last happened), I noticed that the battery was at 100% when it booted in. So, I had the same thought, and have been thinking of moving to the vanilla kernel (where hibernate works out of the box) since Fedora has decided that they and not the user should decide that we should not have support for hibernation (a decision which I am very disappointed with -- per reasoning below).
This decision has the potential to essentially kill hibernation in the long-term because fewer people will use it if something requires additional work to get it going (as happens with Fedora and I think Ubuntu). As a result, less people will be catching bugs and even fewer will be reporting them (of course, reporting within Fedora may not even be allowed anymore since it is disabled by default).
Hibernation besides, being environmentally friendly, also is often, when you are taking a long trip in the middle of nowhere, the only way to get your battery to last while working.
Anyway, sorry for expressing my disappointment.
Part of the problem it Linux has to implement its own hibernation because Intel, one way or another, doesn't provide access to the various power states supported by the hardware. Like in the case of Rapid Start, which appeared to be supported in Windows 8 and is now dead (didn't last long) was something the vendor had to license to get access to the code. I have no idea what they're using now on Windows 10. So the hardware keeps changing. On the one hand the power management stuff in hardware is getting better but the required code isn't going into the kernel. That's just one part where it can fail.
Another part where it can fail now is UEFI Secure Boot. The image file isn't encrypted so it's possible to modify the image and bypass the whole point of Secure Boot. They're are patches but as far as I know they're not upstream. In fact Fedoras UEFI Secure Boot support isn't upstream because they've been dragging their feet on a distro unified position how to support it. That's another part where it won't work, yet anyway.
Next, there's disagreement between systemd, dracut, and anaconda developers on how to provide the hint to the kernel needed for it to find the hibernation image. All the other distros I'm familiar with use resume=<dev> as a boot parameter to do this, but anaconda devs say this is dracut's job to find it. So out of the box it's not even configured for hibernation.
Because of how hibernation works on Linux: the hibernation image is written to disk, then the computer is powered off, to resume you are actually cold booting, going through the bootloader which loads the kernel and initramfs just like a regular boot, but then the kernel sees the hint finds the hibernation image and loads it, it's actually pretty damn slow. If you have a pile of applications and docs open, yes all of that gets resumed as well with resume from hibernation, but not so for a true reboot. So there might still be some savings.
But even if everything none of the above apply, and you've configured it yourself, it can still fail just because of kernel and hardware bugs. I've tried using hibernation, the kernel finds the image, but then rejects it as bad, 100% of the time. So enabling this by default for everyone with no means of per model or per configuration blacklisting is fraught with peril. It's not appropriate to give people the idea their computer will safely hibernate, protecting their data, and then just face plant on resume.
Executive summary: yes, hibernation *is* broken, and may never be fixed.
I have no insight what the desktop folks are looking to build, but my take is that more applications need to save their states automatically. If they get force quit, such as what'd happen during an abrupt power off at critical power, they'd see this "dirty" state and recover on their own. Maybe there's something the DE could do to make that easier for developers to opt into. The idea of manually saving documents is pretty antiquated, we don't do this with mobile devices, there's no good reason why we're still doing this on laptops except it just hasn't caught up. The DE could maybe keep track of what programs are running, and again if upon login finds a "dirty" flag it can autolaunch those programs.
That would be great if the session control in the various DE's was reliable. As a KDE user I find it's a crap shoot. Some apps come back up reliably, some don't. The ones that don't seem to be those written to Gtk rather than Qt (but maybe under Gnome it's the other way round). Typical errors include not remembering which virtual desktop they were on, or sometimes just losing all their tabs (Chrome, I'm looking at you). Luckily I've never lost any data (touch wood).
Anyway between, hardware, firmware, bootloader, kernel, installer, systemd, it's not easy for users to even produce quality bug reports that isolate the actual cause of hibernation not working. "not working" doesn't come close to helping pinpoint the problem. And long term I'm not sure either users or developers have much interest in this working any better than it does, or finding a better way entirely to do it seeing as we just aren't getting enough support from Intel for these sorts of things (or anyone else for that matter).
Exactly. It's an unholy mess.
poc
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.
HTH.
JD
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.
poc
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
____________________________________________________________ Send your photos by email in seconds... TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if3 Works in all emails, instant messengers, blogs, forums and social networks.
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.
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
On Sat, 24 Sep 2016 17:22:56 +0100 "Patrick O'Callaghan" pocallaghan@gmail.com wrote:
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 ...
Same here: jd1008 appears to not have followed the thread, but yes, I (and others discussing this) have all this done but hibernate (sometimes, quite frequently now) fails. The fact that it goes in and comes back sometimes should indicate that this is set correctly. Btw, the last line has no effect because it does not work (yet) and is ignored: it is a bug somewhere on BZ.
Ranajn
____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
On 09/24/2016 10:22 AM, Patrick O'Callaghan wrote:
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
Yes - that must be it. Have you changed it to false, and run grub2-mkconfig and rebooted, and hibernated and rebooted to see if it will resume as it ought to?
Cheers,
JD
On Sat, 2016-09-24 at 11:25 -0600, jd1008 wrote:
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
Yes - that must be it. Have you changed it to false, and run grub2-mkconfig and rebooted, and hibernated and rebooted to see if it will resume as it ought to?
Just tried it and (somewhat to my surprise) it worked. I'll cross my fingers and hope it keeps working.
[One thing I noticed is that alternate lines in the boot menu are now labelled Recovery Mode (i.e. for each kernel version there is now an additional line). This definitely wasn't the case before but I assume it's not related to hibernation, despite the potential confusion between the terms Recover and Restore.]
Thanks for your help.
poc
PS I tried it twice. First time Bluetooth worked, second time it didn't, i.e. it was offline on restore. This is pretty much par for the course.
On 09/24/2016 11:56 AM, Patrick O'Callaghan wrote:
On Sat, 2016-09-24 at 11:25 -0600, jd1008 wrote:
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
Yes - that must be it. Have you changed it to false, and run grub2-mkconfig and rebooted, and hibernated and rebooted to see if it will resume as it ought to?
Just tried it and (somewhat to my surprise) it worked. I'll cross my fingers and hope it keeps working.
[One thing I noticed is that alternate lines in the boot menu are now labelled Recovery Mode (i.e. for each kernel version there is now an additional line). This definitely wasn't the case before but I assume it's not related to hibernation, despite the potential confusion between the terms Recover and Restore.]
Thanks for your help.
poc
PS I tried it twice. First time Bluetooth worked, second time it didn't, i.e. it was offline on restore. This is pretty much par for the course.
I have not figured out the difference between the "recovery" kernels and the non "recovery" kernels in the grub.conf file. Perhaps someone (a developer) could clarify.
Cheers,
JD
On Sat, 2016-09-24 at 12:06 -0600, jd1008 wrote:
On 09/24/2016 11:56 AM, Patrick O'Callaghan wrote:
On Sat, 2016-09-24 at 11:25 -0600, jd1008 wrote:
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
Yes - that must be it. Have you changed it to false, and run grub2-mkconfig and rebooted, and hibernated and rebooted to see if it will resume as it ought to?
Just tried it and (somewhat to my surprise) it worked. I'll cross my fingers and hope it keeps working.
[One thing I noticed is that alternate lines in the boot menu are now labelled Recovery Mode (i.e. for each kernel version there is now an additional line). This definitely wasn't the case before but I assume it's not related to hibernation, despite the potential confusion between the terms Recover and Restore.]
Thanks for your help.
poc
PS I tried it twice. First time Bluetooth worked, second time it didn't, i.e. it was offline on restore. This is pretty much par for the course.
I have not figured out the difference between the "recovery" kernels and the non "recovery" kernels in the grub.conf file. Perhaps someone (a developer) could clarify.
And it failed again, in identical circumstances to the last time when it worked.
poc
On 09/25/2016 12:00 PM, Patrick O'Callaghan wrote:
On Sat, 2016-09-24 at 12:06 -0600, jd1008 wrote:
On 09/24/2016 11:56 AM, Patrick O'Callaghan wrote:
On Sat, 2016-09-24 at 11:25 -0600, jd1008 wrote:
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
Yes - that must be it. Have you changed it to false, and run grub2-mkconfig and rebooted, and hibernated and rebooted to see if it will resume as it ought to?
Just tried it and (somewhat to my surprise) it worked. I'll cross my fingers and hope it keeps working.
[One thing I noticed is that alternate lines in the boot menu are now labelled Recovery Mode (i.e. for each kernel version there is now an additional line). This definitely wasn't the case before but I assume it's not related to hibernation, despite the potential confusion between the terms Recover and Restore.]
Thanks for your help.
poc
PS I tried it twice. First time Bluetooth worked, second time it didn't, i.e. it was offline on restore. This is pretty much par for the course.
I have not figured out the difference between the "recovery" kernels and the non "recovery" kernels in the grub.conf file. Perhaps someone (a developer) could clarify.
And it failed again, in identical circumstances to the last time when it worked.
poc
I strongly suspect a HW issue.
On 09/25/2016 12:21 PM, jd1008 wrote:
On 09/25/2016 12:00 PM, Patrick O'Callaghan wrote:
On Sat, 2016-09-24 at 12:06 -0600, jd1008 wrote:
On 09/24/2016 11:56 AM, Patrick O'Callaghan wrote:
On Sat, 2016-09-24 at 11:25 -0600, jd1008 wrote:
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
Yes - that must be it. Have you changed it to false, and run grub2-mkconfig and rebooted, and hibernated and rebooted to see if it will resume as it ought to?
Just tried it and (somewhat to my surprise) it worked. I'll cross my fingers and hope it keeps working.
[One thing I noticed is that alternate lines in the boot menu are now labelled Recovery Mode (i.e. for each kernel version there is now an additional line). This definitely wasn't the case before but I assume it's not related to hibernation, despite the potential confusion between the terms Recover and Restore.]
Thanks for your help.
poc
PS I tried it twice. First time Bluetooth worked, second time it didn't, i.e. it was offline on restore. This is pretty much par for the course.
I have not figured out the difference between the "recovery" kernels and the non "recovery" kernels in the grub.conf file. Perhaps someone (a developer) could clarify.
And it failed again, in identical circumstances to the last time when it worked.
poc
I strongly suspect a HW issue.
Patrick, please recheck /etc/default/grub and be sure it is as what you set it to that resulted in successful hibernation and reboot.
On Sun, 2016-09-25 at 14:52 -0600, jd1008 wrote:
And it failed again, in identical circumstances to the last time when it worked.
poc
I strongly suspect a HW issue.
Patrick, please recheck /etc/default/grub and be sure it is as what you set it to that resulted in successful hibernation and reboot.
All I know is that I changed GRUB_DISABLE_RECOVERY="false" (from "true") and rebooted. That was the only change. When I tried hibernation it worked (i.e. resuming worked). In fact it worked at least twice, then *with no further change* didn't work. Given the random nature of this it's hard to ascribe causality. One can never discount HW of course, but there are no other symptoms. The system is an i7 CPU in an Intel mobo with 16GB of RAM and root on an SSD formatted as btrfs. Video is an Nvidia GeForce GT 630.
poc
On 09/25/2016 05:07 PM, Patrick O'Callaghan wrote:
On Sun, 2016-09-25 at 14:52 -0600, jd1008 wrote:
And it failed again, in identical circumstances to the last time when it worked.
poc
I strongly suspect a HW issue.
Patrick, please recheck /etc/default/grub and be sure it is as what you set it to that resulted in successful hibernation and reboot.
All I know is that I changed GRUB_DISABLE_RECOVERY="false" (from "true") and rebooted. That was the only change. When I tried hibernation it worked (i.e. resuming worked). In fact it worked at least twice, then *with no further change* didn't work. Given the random nature of this it's hard to ascribe causality. One can never discount HW of course, but there are no other symptoms. The system is an i7 CPU in an Intel mobo with 16GB of RAM and root on an SSD formatted as btrfs. Video is an Nvidia GeForce GT 630.
poc
Just wondering if anything changed between working and not working; i.e. I check the file again. Other than that, hardware and device drivers might be an issue. In case you are using the Nvidia proprietary driver proprietary driver, then as Ed Greshko pointed out, revert to the fedora driver for the graphics card, and retry.
CHeers,
JD
I don't see how GRUB_DISABLE_RECOVERY="false" is related. All that does when true is create extra "(recovery mode)'" menu entries for each kernel that includes one additional boot parameter: single
Saying "it doesn't work" and "it used to work and now it doesn't" is not at all helpful. You need to provide logs, specifically the entire output of 'journalctl -b -o short-monotonic > journal_notworking.log' and then one for the working case, and look through them both to find out what the differences are between them.
There's a 50/50 chance you could just compare dmesg with a working case and non-working case. I'm willing to bet that the kernel is either not finding where the hibernation image is stored, or it doesn't like what it found. The logic for finding the hibernation image is apparently non-trivial, there's no udev or anything available yet so I think it's dracut that has to convert whatever notation you use into major:minor which is what the kernel needs to use to get the image.
On Mon, 2016-09-26 at 12:28 -0600, Chris Murphy wrote:
I don't see how GRUB_DISABLE_RECOVERY="false" is related. All that does when true is create extra "(recovery mode)'" menu entries for each kernel that includes one additional boot parameter: single
OK, well now I now where those extra lines came from.
Saying "it doesn't work" and "it used to work and now it doesn't" is not at all helpful. You need to provide logs, specifically the entire output of 'journalctl -b -o short-monotonic > journal_notworking.log' and then one for the working case, and look through them both to find out what the differences are between them.
Fair enough.
There's a 50/50 chance you could just compare dmesg with a working case and non-working case. I'm willing to bet that the kernel is either not finding where the hibernation image is stored, or it doesn't like what it found. The logic for finding the hibernation image is apparently non-trivial, there's no udev or anything available yet so I think it's dracut that has to convert whatever notation you use into major:minor which is what the kernel needs to use to get the image.
Given that the working and non-working kernels are identical, it's not clear what differences there can be, but if it has to do with device numbering then I guess there could be a timing issue.
poc
On Tue, 2016-09-27 at 06:44 +0800, Ed Greshko wrote:
On 09/27/16 00:19, jd1008 wrote:
In case you are using the Nvidia proprietary driver proprietary driver, then as Ed Greshko pointed out
I have not been involved in this thread and I made no such recommendation in regards to hibernation.
I thought I must have missed something.
poc
On 09/27/16 07:21, Patrick O'Callaghan wrote:
On Tue, 2016-09-27 at 06:44 +0800, Ed Greshko wrote:
On 09/27/16 00:19, jd1008 wrote:
In case you are using the Nvidia proprietary driver proprietary driver, then as Ed Greshko pointed out
I have not been involved in this thread and I made no such recommendation in regards to hibernation.
I thought I must have missed something.
You didn't. I have never used "suspend" or "hibernation" in the Linux environment. So, I know less than nothing about them. So, if you read anything from me where I use words like "hibernate" or "suspend" chances are that I'm talking about bears or inter-galactic travel.
-
Chris Murphy -
Ed Greshko -
fedora -
JD -
Patrick O'Callaghan -
Ranjan Maitra