Hibernate (suspend to disk) fails to resume

[digulla]

Submission type

• [*] Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

228-5.1

NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!

Used distribution

openSUSE Tumbleweed

In case of bug report: Expected behaviour you didn't see

Desktop appearing after resume from hibernate (suspend to disk)

In case of bug report: Unexpected behaviour you saw

System boots, selects the previous kernel, loads initrd (I think, text only visible for very short time), screen goes dark (as if it was switching to graphics mode), screen comes back. Instead of my Desktop, I see the normal boot messages of all the services which systemd is starting.

In case of bug report: Steps to reproduce the problem

Just hibernate on my computer.

If you think this information isn't enough, please provide me with tools and instructions how to make systemd collect the information you need.

[poettering]

Does your distro use systemd-hibernate-generator in the initrd? Do you boot with resume= on the kernel cmdline?

This really sounds like something you should enquire your distro about first, given that it's not clear that systemd is at fault here...

[digulla]

My computer has successfully hibernated for about two years. It stopped working when I upgraded to the Linux Kernel 4.x. GRUB2 hasn't changed in any way I can tell; the boot options (which includes the resume= and nomodeset options) still look the same as ever.

By the look of it, it seems that someone (systemd?) notices that there is a hibernate image on the swap drive and tries to use it - no green messages. At least the first part of the boot looks like it was with kernel 3.6.

Then the screen goes black. Something happens. I don't know what. The machine doesn't reset or crash. Instead of showing the desktop like before, normal systemd boot messages start to scroll.

My guess is that the NVIDIA driver is somehow buggy but I can't prove it unless I know what systemd is doing during boot. So what I would like is tools to somehow record what happens and this information needs to survive a normal boot (not a power fail or hardware reset).

I would imagine an option somewhere which makes systemd reserve a few MB of RAM. During debugging a boot, it should write stuff there. Since I don't see a system reset, the log messages should be there when the system has booted normally after starting from the image in swap has failed.

Using a serial console isn't an option; my PC doesn't have serial ports anymore.

[digulla]

Regarding systemd-hibernate-generator: I see that dracut calls this tool in /usr/lib/dracut/modules.d/95resume/module-setup.sh:

# if systemd is included and has the hibernate-resume tool, use it and nothing else
if dracut_module_included "systemd" && [[ -x $systemdutildir/systemd-hibernate-resume ]]; then
    inst_multiple -o \
                  $systemdutildir/system-generators/systemd-hibernate-resume-generator \
                  $systemdsystemunitdir/systemd-hibernate-resume@.service \
                  $systemdutildir/systemd-hibernate-resume
    return 0
fi

lsinitrd|&grep systemd matches 170 times including:

...
usr/lib/systemd/systemd-hibernate-resume
...
usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
...

[poettering]

OK, please contact your distro for help first. This really doesn't look like a systemd issue, but some kernel/driver issue, and with the nvidia driver all bets are off anyway. If the distro folks find that this is a bug in systemd after all, please file a new issue.

Sorry!

[digulla]

I talked to the distro guys who can't help me because they also can't telepathically look at my computer. Your software is in control when bad stuff happens and you're the only realistic chance to find out anything.

[poettering]

Well, for starters you said that you updated the kernel, and it broke then, and all that in conjunction with the nvidia drivers. This strongly suggests that you have a kernel/driver/nvidia problem, not a systemd problem. In fact there's nothing pointing towards systemd here, and this is a systemd issue tracker. Hence please, unless there's some real hint that this is caused by systemd, please ask the downstream/kernel/nvidia people for help, first. Thank you for understanding.

[digulla]

I can't understand. Nvidia ignores me, the kernel guys say "well, it boots, so what do you want?"

Your software is in control when the issue happens. You are the only person who can provide me with the necessary information to go to anyone else.

I understand that you built a software which can't write log at important stages of a resume. Design mistakes like that happen. I'm just asking that you fix it. I need to know exactly how far systemd gets during resume. Without that, everyone is going to say what you just said: We can't help you, need more information, might be someone else's problem.

[vcaputo]

@digulla You could try bisecting the kernel if this is reliably reproducible, since it sounds like a kernel version change caused the problem.

Also, you may be able to setup the linux console over USB for aiding in debugging.

I agree with @poettering though, this isn't really the appropriate place for discussing this.

[poettering]

@digulla well, you are using opensuse tumbleweed and use closed source drivers. That means you must be willing to deal with the fallout of that choice, and debug this further.

note that systemd is not responsible for hibernation nor thawing. All we do is echo some string in to a file in /sys that asks the kernel to thaw the hibernation image. That is all. Also, our code that does this hasn't changed in quite some time. Hence: the work systemd does here is trivial and hasn't changed much. The heavy lifting is all done by the kernel and its drivers. And you are using a particularly questionable closed source driver, hence please understand that we can't really help you there.

[arvidjaar]

@digulla
From your description it sounds like either bootloader does not boot correct entry, or kernel attempts to resume but fails or no resume is attempted in the first place. Neither of which is directly related to systemd. Please ask your question either on openSUSE forums or on opensuse mailing list.

[digulla]

note that systemd is not responsible for hibernation nor thawing. All we do is echo some string in to a file in /sys that asks the kernel to thaw the hibernation image.

Thanks. That was the information which I was missing.

you may be able to setup the linux console over USB for aiding in debugging.

Do you have any additional information on this? Google didn't turn up anything useful and it's not mentioned in http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/

I think I could live with losing all messages that happen before the kernel loads (i.e. all the GRUB logs) and with losing all kernel logs until USB is ready (I assume here that USB is loaded long before the graphics drivers, since the keyboard works).