Comment # 12 on bug 1020965 from Michal Suchanek

(In reply to George Anchev from comment #11)

> No idea what the 'tlp auto' fail means and why it appears.

There is helpful 'cnf' command which tells you what package installs the
command and you can read the package description then.

> ============================================================
> 
> Then I booted the system setting initcall_debug and no_console_suspend in
> GRUB on boot, like explained here (after doing the "STFW" step):
> 
> https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-
> issues
> 
> After booting completed I ran:
> 
> # systemctl hibernate
> 
> The system powers off after a few seconds of hard disk activity. No any
> messages on screen, nothing showed in 'journalctl -f' while watching it
> through SSH. Pressing the power button doesn't restore from hibernate but
> instead boots through GRUB like from a shutdown state.

Obviously ssh will not work. If you are running X you might have better luck
switching to text console. You might also want to increase loglevel. 

> 
> After booting in the journal I read:
> 
> ...
> Feb 16 18:40:01 acer systemd[1]: Starting Resume from hibernation using
> device /dev/sda1...
> Feb 16 18:40:01 acer systemd-hibernate-resume[284]: Could not resume from
> '/dev/sda1' (8:1).
> Feb 16 18:40:01 acer kernel: PM: Starting manual resume from disk
> Feb 16 18:40:01 acer kernel: PM: Hibernation image partition 8:1 present
> Feb 16 18:40:01 acer kernel: PM: Looking for hibernation image.
> Feb 16 18:40:01 acer kernel: PM: Image not found (code -22)
> Feb 16 18:40:01 acer kernel: PM: Hibernation image not present or could not
> be loaded.

This means a hibernation image was not created.

> ...
> 
> 
> Trying the same thing without initcall_debug and no_console_suspend
> hibernates the system just like explained initially but upon powering it on
> the monitor is off, the system doesn't react to any key press or other event
> and trying to connect to it through SSH gives "No route to host". The only
> way to get out of this is hardware reset.
...
> Let me know if that information is enough for you to forward this upstream.
> If it is not - please provide steps for further debugging in layman terms
> (hopefully not using "STFW"). Thank you.

No, you did not diagnose why the system fails to resume nor did you provide
kernel logs at which somebody could look. So there is no information to work
with.