13.2 and hibernate amnesia

English Install/Boot/Login
#1

Hi all! I have 13.2 installed and use hibernate everyday.

The problem is when the system turns on, it proceeds straight to a cold boot, complete with an fsck. Turning off for hibernate seems to work fine, as in the system manages to save state then turn off properly. I’ve tried disabling zram before hibernate and it doesn’t make a difference. Swap partition is 8GB, RAM is 16GB, but images don’t exceed 4GB most of the time. Running sudo pm-hibernate makes no difference either.

Resuming from hibernate sporiadically used to work before (it used to resume properly at times), but after editing /etc/susend.conf to enable “suspend loglevel = 7”, resuming from hibernate broke completely.
When hibernate used to work and resumed properly, sometimes it doesn’t go to the desktop after loading, requiring me to press MagicSysRq+E to get to the desktop.

Laptop:

Asus N55SF
i5-2450M
Nvidia GT555M
16GB RAM

Thank you!

dmesg and pm-suspend.log
https://gist.github.com/tsdmgz/eeed0b67fb7b335cd88d

/etc/fstab


UUID=57539cb4-bc4c-474e-a9a5-29cca9dffab7 /                    ext4       acl,user_xattr        1 1
UUID=ed04644d-acd5-48aa-8e40-0ba013d293eb /boot                ext2       acl,user_xattr        1 2
UUID=2345be2c-1a5d-4d94-80d2-09b70339d544 swap                 swap       defaults              0 0
UUID=d2b42b5b-3082-4251-a20e-b39c4ab08320 /home                ext4       defaults              1 2
UUID=DC7A3FE87A3FBE58 /mnt/d               ntfs-3g    users,gid=users,fmask=113,dmask=002,locale=en_US.UTF-8 0 0
UUID=993f858f-5108-4451-89d7-82b5f473735d /mnt/d/work		ext4	defaults		0 0
tmpfs                /tmp                 tmpfs      defaults              0 0

//xiaoyun.dmgzhome/share	/mnt/z	cifs	noauto,_netdev,file_mode=0666,dir_mode=0777,username=guest,password=,users,gid=users	0	0

/proc/swaps


Filename                                Type            Size    Used    Priority
/dev/sda8                               partition       8288116 0       -1
/dev/zram0                              partition       524284  0       100
/dev/zram1                              partition       524284  0       100
/dev/zram2                              partition       524284  0       100
/dev/zram3                              partition       524284  0       100

/etc/default/grub


# Modified by YaST2. Last modification on Sat Jan 17 13:23:07 PHT 2015
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# For the new kernel it try to figure out old parameters. In case we are not able to recognize it (e.g. change of flavor or strange install order ) it it use as fallback installation parameters from /etc/sysconfig/bootloader

# If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update
# /boot/grub2/grub.cfg.
GRUB_DISTRIBUTOR=openSUSE
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=1
GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-uuid/2345be2c-1a5d-4d94-80d2-09b70339d544 showopts elevator=deadline i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 nouveau.modeset=0"
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY="showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe"
GRUB_CMDLINE_LINUX=""
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=auto
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
# Skip 30_os-prober if you experienced very slow in probing them
# WARNING foregin OS menu entries will be lost if set true here
GRUB_DISABLE_OS_PROBER=false
# Set to 'y' for grub to be installed on an encrypted partition
GRUB_ENABLE_CRYPTODISK=n
SUSE_BTRFS_SNAPSHOT_BOOTING=true
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt

suspend.conf


#############################################################################
##
## note:
## using pm-utils or powersaved, this file (/etc/suspend.conf) only serves as
## a template, image_size and resume_device are filled in dynamically
## and the generated /var/lib/s2disk.conf is used to suspend.
## _If_ you enter stuff here, it will be copied to that file unchanged,
## but this might skip some features and sanity checks.
##
#############################################################################
##
## your snapshot device. You should not need to change this.
# snapshot device = /dev/snapshot
#
## enter your swap device here. Read the warning on pm-utils above, please!
#resume device = <path_to_resume_device_file>
#
## image size will also be filled in by pm-utils
#image size = 350000000
#
suspend loglevel = 7
#max loglevel =
#
## compute checksum will slow down suspend and resume.
## Debugging option, default n
#compute checksum = y
#
## compression will often speed up suspend and resume (default y)
#compress = n
#
## encryption support is rather basic right now - e.g. USB keyboards will not
## work to enter the key in the standard initrd, also beware of
## non-US keyboard layouts. Only use this if you know what you are doing.
#encrypt = y
#
## RSA key file that is used for encryption
#RSA key file = /etc/suspend.key
#
## start writing out the image early, before buffers are full.
## will most of the time speed up overall writing time (default y)
#early writeout = n
#
## use splash picture? (default y)
#splash = y
#
## shutdown method:
## platform - go through ACPI BIOS to power off the machine (default on
##            machines that support it)
## shutdown - just power off like after a shutdown
## reboot   - reboot instead of powering off. For debugging only.
#shutdown method = platform
#
## resume offset: for use with swapfiles, use "swap-offset" to find out.
#resume offset = 12345
#
## pause after resume for n seconds, so that the timing information can
## actually be read (default 0 => don't pause)
#resume pause = 3
#
## use threads for suspend? (default n)
## this hugely speeds up encryption and also compression on mulitcore machines
#threads = y
#2

Maybe it works if you uninstall pm-utils?
They are deprecated anyway.

#3

Uninstalled pm-utils, rebooted, and attempted another hibernate. It still went straight into cold boot.

#4

BTRFS on root?? Could be the grub problem of not being able to write to BTRFS??? But usually it gets stuck in wake from sleep mode. try erasing

/boot/grub2/grubenv

#5

???
You’re completely mixing things up.

When resuming from sleep mode, grub is not even started.

And the problem that grub2 cannot write to btrfs “only” causes the boot menu to disappear when resume from hibernate fails. But it doesn’t cause the resume to fail.

@gjie:
You don’t have “noresume” on your kernel commandline by chance? But I think the hibernation should be aborted in that case.
OTOH, there are known problems with resuming and the nvidia driver. But it should at least resume, there might be graphics problems afterwards though. Still, try to disable desktop effects before you hibernate. Does this help?

And a side-note: IMHO you’re playing “russian roulette” anyway by hibernating with 8GiB swap for 16GiB RAM. Even if it is not the problem here.

PS: your kernel command line is quite long:

Command line: BOOT_IMAGE=/vmlinuz-3.16.7-7-desktop root=UUID=57539cb4-bc4c-474e-a9a5-29cca9dffab7 resume=/dev/disk/by-uuid/2345be2c-1a5d-4d94-80d2-09b70339d544 showopts elevator=deadline i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 nouveau.modeset=0

Maybe some option is causing the resume to fail? Try to remove them all (everything after “showopts”) as a test.
And check that the resume= option specifies the correct partition, i.e. that /dev/disk/by-uuid/2345be2c-1a5d-4d94-80d2-09b70339d544 is indeed your swap partition.

#6

Sorry, you posted your fstab earlier anyway, and this seems to be correct.

Well, I can only suspect then that the zram is causing the problem.
Try without, does it work then?

I cannot help with that at all though.

#7

I agree but that was worth a shot. since the control is dove via the grubenv file . Grub is still in control of the resume boot that is were the resume info comes from

#8

The grubenv file doesn’t “control” anything. It can be used to set an entry to boot the next time though, which would apply here of course.
So if a wrong entry would be specified there, the resume might not be done at all (if that entry has the “noresume” option e.g.).

But the pm-utils log showed that the first entry was set by the hibernation, i.e. “grub-once 0” was called.
And the kernel command line shows that this one doesn’t have the “noresume” parameter.

Grub is still in control of the resume boot that is were the resume info comes from

That’s true.
But deleting grubenv wouldn’t help at all (even if it would be the culprit), as this is created by the hibernation process in the first place.

#9

Well if it is created right. if it is corrupted or created wrong it would effect the boot. It would need to be present and correct to trigger (thus control) the resume process and grub would fall through and do a normal boot sequence and not do the resume. My understanding is that the file must be present and assumed formed right to trigger the resume. If the file is not present or ill formed then a normal boot happens and I assume the BTRFS work around does not remove the file since it is a normal boot and it should not be there in that case.

#10

It would (and does anyway) affect the boot, yes. But not in the way as you seem to think.

It would need to be present and correct to trigger (thus control) the resume process and grub would fall through and do a normal boot sequence and not do the resume. My understanding is that the file must be present and assumed formed right to trigger the resume. If the file is not present or ill formed then a normal boot happens and I assume the BTRFS work around does not remove the file since it is a normal boot and it should not be there in that case.

Your understanding is wrong.
grubenv is not at all needed to trigger the resume.

You need a correct resume= option on the kernel command line to trigger the resume, and that is (should be) part of the menu entry in grub.cfg.
grubenv is only used/necessary to set the correct menu entry to be booted (in this case it’s the default one anyway, so grubenv is redundant regarding this), and to hide the boot menu so that the user cannot select a different entry by mistake (this could even cause data loss).

And the second part is a problem with /boot on btrfs, as grub2 cannot remove that entry from grubenv so the menu stays hidden.
But again, this would not have any influence on the resume itself, and the resume script that is run during/after the resume removes that entry in grubenv as a workaround for btrfs.

#11

If it is not erased in a normal resume then the resume sequence is repeated on subsequent boots so its existence does control the resume. Removing it allows a normal boot. It is not at all unreasonable that a corrupted file may cause a normal boot when a resume is called for. some code like this in the program that creates it could cause the file never to be adjusted

If .NOT. file(“grubenv”)
createfile()
endif

So bad file stays. resume does not work right

I don’t know if it is true but it is plausible and worth a look

#12

Wrong.
The resume sequence is not at all repeated.

Just the set entry is booted again and again, and the boot menu stays hidden.

Removing it allows a normal boot.

Yes.
But not removing it allows a normal boot as well. You just don’t see a boot menu and therefore cannot select a different entry.

It is not at all unreasonable that a corrupted file may cause a normal boot when a resume is called for. some code like this in the program that creates it could cause the file never to be adjusted

Yes, this would happen if it specifies a boot entry with the “noresume” parameter (like e.g. the recovery mode entries) as I already wrote.
But in the OP’s case entry 0 has been set, which has “resume=xxx” on the kernel command line as indicated by the logs.

If .NOT. file(“grubenv”)
createfile()
endif

There’s noting like that in the “program that creates it”.

So bad file stays. resume does not work right

No. The resume script resets the “next_entry=” option that’s in there completely.

I don’t know if it is true but it is plausible and worth a look

No it isn’t.
And again, even if the wrong entry would be set, it would not help at all to remove grubenv. This entry is set by hibernation, you would have to remove it before you resume.

#13

Okay, did some testing and made me go WTF.

Removed everything after “showopts”, ran grub2-mkconfig, and rebooted. Resume worked.
Several reboot-and-hibernate tests later, adding anything other than the default kernel command line breaks resume.

@gogalthorp

As per fstab, I don’t have any btrfs partitions around.

OT: I’ve been trying to reply with Thunderbird over NNTP and I can’t seem to get replies to work? If a duplicate shows up, sorry about that.

#14

Okay, did some testing and made me go WTF.

Removed everything after “showopts”, ran grub2-mkconfig, and rebooted. Resume worked.
Several reboot-and-hibernate tests later, adding anything other than the default kernel command line breaks resume.

@gogalthorp

As per fstab, I don’t have any btrfs partitions around.

On 2015-03-12 21:06, wolfi323 wrote:
>
> gogalthorp;2699347 Wrote:
>> BTRFS on root?? Could be the grub problem of not being able to write to
>> BTRFS??? But usually it gets stuck in wake from sleep mode. try erasing
>>
>> /boot/grub2/grubenv
> ???
> You’re completely mixing things up.
>
> When resuming from sleep mode, grub is not even started.
>
> And the problem that grub2 cannot write to btrfs “only” causes the boot
> menu to disappear when resume from hibernate fails. But it doesn’t cause
> the resume to fail.
>
> @gjie:
> You don’t have “noresume” on your kernel commandline by chance? But I
> think the hibernation should be aborted in that case.
> OTOH, there are known problems with resuming and the nvidia driver. But
> it should at least resume, there might be graphics problems afterwards
> though. Still, try to disable desktop effects before you hibernate. Does
> this help?
>
> And a side-note: IMHO you’re playing “russian roulette” anyway by
> hibernating with 8GiB swap for 16GiB RAM. Even if it is not the problem
> here.
>
> PS: your kernel command line is quite long:
>
> Code:
> --------------------
> Command line: BOOT_IMAGE=/vmlinuz-3.16.7-7-desktop root=UUID=57539cb4-bc4c-474e-a9a5-29cca9dffab7 resume=/dev/disk/by-uuid/2345be2c-1a5d-4d94-80d2-09b70339d544 showopts elevator=deadline i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 nouveau.modeset=0
> --------------------
>
> Maybe some option is causing the resume to fail? Try to remove them all
> (everything after “showopts”) as a test.
> And check that the resume= option specifies the correct partition, i.e.
> that /dev/disk/by-uuid/2345be2c-1a5d-4d94-80d2-09b70339d544 is indeed
> your swap partition.
>
>

#15

Anything?
That would be a bit surprising.

And I’d think something like “elevator=deadline” or “nouveau.modeset=0” should not influence resume at all.
Hm, I have no idea at the moment why that would be…

But what happens if you add “splash=silent quiet” before showopts? That’s there by default at least, although I have to admit I don’t really think that it should break resume if missing…

#16

On Thu 12 Mar 2015 05:06:02 PM CDT, gjie wrote:
<snip>

i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1

Hi
Just to add the i915 options are different for the 3.16 kernel, it’s
i915.enable_rc6 and i915.enable_fbc.

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.36-38-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

#17

OK no BTRFS then my idea was wrong looks like it is something else

But to my point with the no menu problem is caused by the grubenv not being erased and yes it will continue with resume on each boot until it is removed. we have seen this multiple times. Yes there is a supposed fix that seems to work most time but sometimes it does not as per the several threads concerning no boot menu show that were fixed by erasing that file.

#18

But there never was mentioned a “no menu problem” in this thread.

and yes it will continue with resume on each boot until it is removed.

No, it won’t.
After the first try to resume, there won’t be any hibernation image in the swap partition any more, so the kernel will not try a resume.

And again, grub2 or grubenv does not trigger any resume at all. The kernel does itself, if it finds a hibernation image on the resume partition.

we have seen this multiple times.

I have never seen that the system keeps trying to resume forever.
I don’t know what you have seen, but you seem to have hallucinated… :stuck_out_tongue:
AFAIK you never used btrfs yourself anyway, or do you meanwhile?

Yes there is a supposed fix that seems to work most time but sometimes it does not as per the several threads concerning no boot menu show that were fixed by erasing that file.

But “boot menu missing” is not at all the same as “resuming from hibernation”.

I already wrote more than once that an existing grubenv with a “next_entry” line will cause the boot menu to be hidden. But it won’t cause any resume from hibernation.

And the OP’s problem was that there’s no resume taking place at all anyway. So it was clear from the start that this “grub2 can’t write to btrfs” problem was not the issue here.

#19

Resume works when “splash=silent quiet” before “showopts” was added. Just to make sure, I removed those two options and put “elevator=deadline” back in and resume broke again. So, yes, anything it seems.

It gets weird.
Putting everything back together:


"splash=silent quiet showopts elevator=deadline i915.enable_rc6=1 i915.enable_fbc=1 i915.lvds_downclock=1 nouveau.modeset=0"

(thanks for the new params @malcolmlewis!), resume works properly!

Although “i915.enable_fbc=1 i915.lvds_downclock=1” had to be removed because one of these was giving me weird display corruption issues, even with compositing off.

“splash=silent quiet” was originally taken out because I wanted to see the pretty text going down while booting. Goes great for freaking out friends when they see it for the first time also.

@gogalthorp

Sorry, this is a completely different problem here.

On 2015-03-13 01:26, wolfi323 wrote:
>
> gjie;2699389 Wrote:
>> Removed everything after “showopts”, ran grub2-mkconfig, and rebooted.
>> Resume worked.
>> Several reboot-and-hibernate tests later, adding anything other than the
>> default kernel command line breaks resume.
>>
> Anything?
> That would be a bit surprising.
>
> And I’d think something like “elevator=deadline” or “nouveau.modeset=0”
> should not influence resume at all.
> Hm, I have no idea at the moment why that would be…
>
> But what happens if you add “splash=silent quiet” before showopts?
> That’s there by default at least, although I have to admit I don’t
> really think that it should break resume if missing…
>
>

#20

Wow. This would sound like a (kernel?) bug to me.

Just OOC, would specifying those additional parameters before “showopts” work?
Or removing “showopts” completely? This doesn’t really make sense with grub2 any more anyway I think. It was used with grub1 to specify which part should be displayed in the editable boot options line in the boot menu.