[opensuse-factory] how to debug hibernation issue

older
[opensuse-factory] Package relying...

Axel Braun

12 Feb 2017 12 Feb '17

18:42

Hi, I made an upgrade on my Asus eeePC from 13.1 to Tumbleweed in a single run (first update zypper, then run zypper dup). That worked perfectly, no issues so far, except that hibernation does not work (suspend does!). System boots into the hibernation file, screen gets black, and after some seconds it reboots journalctl issues: Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 2. Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 1. Feb 12 19:20:33 eeePC systemd[1]: Starting Resume from hibernation using device /dev/sda1... Feb 12 19:20:33 eeePC systemd[1]: Reached target Initrd Root Device. Feb 12 19:20:33 eeePC systemd-hibernate-resume[287]: Could not resume from '/dev/sda1' (8:1). Feb 12 19:20:33 eeePC kernel: PM: Starting manual resume from disk Feb 12 19:20:33 eeePC kernel: PM: Hibernation image partition 8:1 present Feb 12 19:20:33 eeePC kernel: PM: Looking for hibernation image. Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2 Obviously the image file was not written properly? Any idea what I could try? Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Show replies by date

Carlos E. R.

12 Feb 12 Feb

19:36

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-02-12 19:42, Axel Braun wrote:

...

Hi,

I made an upgrade on my Asus eeePC from 13.1 to Tumbleweed in a single run (first update zypper, then run zypper dup). That worked perfectly, no issues so far, except that hibernation does not work (suspend does!).

System boots into the hibernation file, screen gets black, and after some seconds it reboots

journalctl issues: Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 2. Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 1. Feb 12 19:20:33 eeePC systemd[1]: Starting Resume from hibernation using device /dev/sda1... Feb 12 19:20:33 eeePC systemd[1]: Reached target Initrd Root Device. Feb 12 19:20:33 eeePC systemd-hibernate-resume[287]: Could not resume from '/dev/sda1' (8:1). Feb 12 19:20:33 eeePC kernel: PM: Starting manual resume from disk Feb 12 19:20:33 eeePC kernel: PM: Hibernation image partition 8:1 present Feb 12 19:20:33 eeePC kernel: PM: Looking for hibernation image. Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2

Obviously the image file was not written properly?

Or to a different device... Check that fstab and the kernel line both point to the same swap partition. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAliguS0ACgkQja8UbcUWM1zKOAD+LVRvqhu8yNapWv7C9axgSgkS 7l9jg6EfUfUB9X2zsQ0A/3KTxojgRrd6wVAciALrHrpNNMlmFSvbacbibQLPUioD =KQxT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Axel Braun

20:23

Am 12. Februar 2017 20:36:13 MEZ schrieb "Carlos E. R." :

...

On 2017-02-12 19:42, Axel Braun wrote:

...
Hi,

I made an upgrade on my Asus eeePC from 13.1 to Tumbleweed in a single run (first update zypper, then run zypper dup). That worked perfectly, no issues so far, except that hibernation does not work (suspend does!).

System boots into the hibernation file, screen gets black, and after some seconds it reboots

journalctl issues: Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 2. Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 1. Feb 12 19:20:33 eeePC systemd[1]: Starting Resume from hibernation using device /dev/sda1... Feb 12 19:20:33 eeePC systemd[1]: Reached target Initrd Root Device. Feb 12 19:20:33 eeePC systemd-hibernate-resume[287]: Could not resume from '/dev/sda1' (8:1). Feb 12 19:20:33 eeePC kernel: PM: Starting manual resume from disk Feb 12 19:20:33 eeePC kernel: PM: Hibernation image partition 8:1 present Feb 12 19:20:33 eeePC kernel: PM: Looking for hibernation image. Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2

Obviously the image file was not written properly?

Or to a different device... Check that fstab and the kernel line both point to the same swap partition.

Both point to /dev/sda1 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Carlos E. R.

20:27

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2017-02-12 21:23, Axel Braun wrote:

...

Am 12. Februar 2017 20:36:13 MEZ schrieb "Carlos E. R." <>:

...

...
...
journalctl issues: Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 2. Feb 12 19:20:33 eeePC systemd[1]: Found device ASUS-JM_S41_SSD 1. Feb 12 19:20:33 eeePC systemd[1]: Starting Resume from hibernation using device /dev/sda1... Feb 12 19:20:33 eeePC systemd[1]: Reached target Initrd Root Device. Feb 12 19:20:33 eeePC systemd-hibernate-resume[287]: Could not resume from '/dev/sda1' (8:1). Feb 12 19:20:33 eeePC kernel: PM: Starting manual resume from disk Feb 12 19:20:33 eeePC kernel: PM: Hibernation image partition 8:1 present Feb 12 19:20:33 eeePC kernel: PM: Looking for hibernation image. Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2

Obviously the image file was not written properly?

Or to a different device... Check that fstab and the kernel line both point to the same swap partition.

Both point to /dev/sda1

Verify thoroughly. Read the log, check the kernel line and compare. I bet they differ. - -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAligxToACgkQja8UbcUWM1wAUgEAoL3DyJ48TQCyCvyANRqZ0gw+ WoHD0evD36Ru8RXknYIBAJCHeVNzfSoKv9D5xcaGuT/rtmu5jiGUq5ElTVlThXej =kr7E -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Patrick Shanahan

21:29

* Carlos E. R. [02-12-17 15:30]:

...

On 2017-02-12 21:23, Axel Braun wrote:

...
Am 12. Februar 2017 20:36:13 MEZ schrieb "Carlos E. R." <>: [....]

...
...
Obviously the image file was not written properly?

Or to a different device... Check that fstab and the kernel line both point to the same swap partition.

Both point to /dev/sda1

Verify thoroughly. Read the log, check the kernel line and compare. I bet they differ.

and/or "/dev/sda1" is not necessarily the same drive on every boot. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Axel Braun

13 Feb 13 Feb

08:31

New subject: Aw: Re: [opensuse-factory] how to debug hibernation issue

...

Gesendet: Sonntag, 12. Februar 2017 um 22:29 Uhr Von: "Patrick Shanahan" An: opensuse-factory@opensuse.org Betreff: Re: [opensuse-factory] how to debug hibernation issue

* Carlos E. R. [02-12-17 15:30]:

...
On 2017-02-12 21:23, Axel Braun wrote:

...
Am 12. Februar 2017 20:36:13 MEZ schrieb "Carlos E. R." <>: [....]

...
...
Obviously the image file was not written properly?

Or to a different device... Check that fstab and the kernel line both point to the same swap partition.

Both point to /dev/sda1

Verify thoroughly. Read the log, check the kernel line and compare. I bet they differ.

and/or "/dev/sda1" is not necessarily the same drive on every boot.

This should clearly not happen on a system with a single HDD inside... Nevertheless, I have tried disk-by-ID as well, but that does not change the result Cheers Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Oliver Neukum

15 Feb 15 Feb

12:24

Am Sonntag, den 12.02.2017, 19:42 +0100 schrieb Axel Braun:

...

Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2

Obviously the image file was not written properly? Any idea what I could try?

You are running into a safety feature. The "sacrificial" kernel clears the hibernation signature on the swap partition. This is necessary because if the resumption fails you'd be in an eternal boot loop. Essentially a driver crashes when it needs to resume. Debugging this is usually cumbersome, but straight forward. 1. You determine whether the the user space resumption code is faulty. To do so you do a brute force suspension echo "disk" > /sys/power/state This will make the kernel do a brute force suspension with an uncompressed image. 2. If that also fails you need to identify the failing driver. As tedious as it sounds, blacklist more and more drivers until your system survives a cycle. HTH Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Axel Braun

22:51

Am Mittwoch, 15. Februar 2017, 13:24:58 CET schrieb Oliver Neukum:

...

Am Sonntag, den 12.02.2017, 19:42 +0100 schrieb Axel Braun:

...
Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2

Obviously the image file was not written properly? Any idea what I could try?

You are running into a safety feature. The "sacrificial" kernel clears the hibernation signature on the swap partition. This is necessary because if the resumption fails you'd be in an eternal boot loop.

Essentially a driver crashes when it needs to resume. Debugging this is usually cumbersome, but straight forward.

1. You determine whether the the user space resumption code is faulty. To do so you do a brute force suspension

echo "disk" > /sys/power/state

This will make the kernel do a brute force suspension with an uncompressed image.

Same as before, hibernation and no proper wake-up

...

2. If that also fails you need to identify the failing driver. As tedious as it sounds, blacklist more and more drivers until your system survives a cycle.

the point to start is probably the list of loaded modules (lsmod) then match against PCI and USB hardware, and make a guess what is not needed, correct? Thanks Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Oliver Neukum

16 Feb 16 Feb

09:33

Am Mittwoch, den 15.02.2017, 23:51 +0100 schrieb Axel Braun:

...

...
2. If that also fails you need to identify the failing driver. As tedious as it sounds, blacklist more and more drivers until your system survives a cycle.

the point to start is probably the list of loaded modules (lsmod) then match against PCI and USB hardware, and make a guess what is not needed, correct?

Yes. I suggest you start with the graphics driver. To do that you need to boot with "nomodeset". It is the most likely culprit. HTH Oliver -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Axel Braun

19 Feb 19 Feb

19:06

New subject: Aw: Re: [opensuse-factory] how to debug hibernation issue

...

Gesendet: Mittwoch, 15. Februar 2017 um 13:24 Uhr Von: "Oliver Neukum" An: "Axel Braun" , "openSUSE Usergroup" Betreff: Re: [opensuse-factory] how to debug hibernation issue

Am Sonntag, den 12.02.2017, 19:42 +0100 schrieb Axel Braun:

...
Feb 12 19:20:33 eeePC kernel: PM: Image not found (code -22) Feb 12 19:20:33 eeePC kernel: PM: Hibernation image not present or could not be loaded. Feb 12 19:20:33 eeePC systemd[1]: Started Resume from hibernation using device /dev/sda1. Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems (Pre). Feb 12 19:20:33 eeePC systemd[1]: Reached target Local File Systems. Feb 12 19:20:33 eeePC systemd[1]: Reached target System Initialization. Feb 12 19:20:33 eeePC systemd[1]: Reached target Basic System. Feb 12 19:20:33 eeePC systemd[1]: Starting File System Check on /dev/disk/by-uuid/efb6a106-11a1-4537-baac-2d2

Obviously the image file was not written properly? Any idea what I could try?

You are running into a safety feature. The "sacrificial" kernel clears the hibernation signature on the swap partition. This is necessary because if the resumption fails you'd be in an eternal boot loop.

Essentially a driver crashes when it needs to resume. Debugging this is usually cumbersome, but straight forward.

1. You determine whether the the user space resumption code is faulty. To do so you do a brute force suspension

echo "disk" > /sys/power/state

This will make the kernel do a brute force suspension with an uncompressed image.

2. If that also fails you need to identify the failing driver. As tedious as it sounds, blacklist more and more drivers until your system survives a cycle.

The guess to start with nomodeset gave a horrible screen resolution, but did not survive a hibernation. Any obvious driver to start with? ac 16384 0 acpi_cpufreq 24576 0 arc4 16384 2 ata_generic 16384 0 ata_piix 32768 2 ath 28672 1 ath5k ath5k 147456 0 atl1e 40960 0 battery 16384 0 button 16384 1 i915 cfg80211 573440 3 mac80211,ath,ath5k coretemp 16384 0 dm_mod 114688 1 dm_multipath dm_multipath 28672 0 drm 335872 11 i915,drm_kms_helper drm_kms_helper 159744 1 i915 eeepc_laptop 24576 0 ehci_hcd 77824 1 ehci_pci ehci_pci 16384 0 fb_sys_fops 16384 1 drm_kms_helper fjes 32768 0 i2c_algo_bit 16384 1 i915 i2c_i801 28672 0 i2c_smbus 16384 1 i2c_i801 i915 1310720 9 ip6table_filter 16384 1 ip6table_mangle 16384 0 ip6table_raw 16384 1 ip6_tables 20480 3 ip6table_mangle,ip6table_filter,ip6table_raw ip6t_REJECT 16384 3 iptable_filter 16384 1 iptable_raw 16384 1 ip_tables 20480 2 iptable_filter,iptable_raw ipt_REJECT 16384 3 iTCO_vendor_support 16384 1 iTCO_wdt iTCO_wdt 16384 0 joydev 20480 0 lpc_ich 20480 0 mac80211 749568 1 ath5k mfd_core 16384 1 lpc_ich Module Size Used by nf_conntrack 110592 6 nf_conntrack_ipv6,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_conntrack_netbios_ns,xt_CT,xt_conntrack nf_conntrack_broadcast 16384 1 nf_conntrack_netbios_ns nf_conntrack_ipv4 16384 3 nf_conntrack_ipv6 20480 3 nf_conntrack_netbios_ns 16384 0 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_defrag_ipv6 24576 1 nf_conntrack_ipv6 nf_log_common 16384 2 nf_log_ipv6,nf_log_ipv4 nf_log_ipv4 16384 5 nf_log_ipv6 16384 5 nf_reject_ipv4 16384 1 ipt_REJECT nf_reject_ipv6 16384 1 ip6t_REJECT option 45056 0 pcspkr 16384 0 rfkill 28672 5 eeepc_laptop,cfg80211 scsi_dh_alua 20480 0 scsi_dh_emc 16384 0 scsi_dh_rdac 20480 0 serio_raw 16384 0 sg 36864 0 shpchp 32768 0 snd 81920 15 snd_hda_intel,snd_hwdep,snd_seq,snd_hda_codec,snd_timer,snd_hda_codec_generic,snd_seq_device,snd_hda_codec_realtek,snd_pcm snd_hda_codec 131072 3 snd_hda_intel,snd_hda_codec_generic,snd_hda_codec_realtek snd_hda_codec_generic 73728 1 snd_hda_codec_realtek snd_hda_codec_realtek 86016 1 snd_hda_core 77824 4 snd_hda_intel,snd_hda_codec,snd_hda_codec_generic,snd_hda_codec_realtek snd_hda_intel 32768 3 snd_hwdep 16384 1 snd_hda_codec snd_pcm 114688 3 snd_hda_intel,snd_hda_codec,snd_hda_core snd_seq 65536 0 snd_seq_device 16384 1 snd_seq snd_timer 32768 2 snd_seq,snd_pcm soundcore 16384 1 snd sparse_keymap 16384 1 eeepc_laptop syscopyarea 16384 1 drm_kms_helper sysfillrect 16384 1 drm_kms_helper sysimgblt 16384 1 drm_kms_helper thermal 20480 0 tpm 45056 2 tpm_tis,tpm_tis_core tpm_tis 16384 0 tpm_tis_core 20480 1 tpm_tis uas 20480 0 uhci_hcd 40960 0 usbcore 241664 9 uvcvideo,usb_storage,ehci_hcd,uhci_hcd,usbserial,option,uas,usb_wwan,ehci_pci usbserial 45056 2 option,usb_wwan usb_storage 57344 1 uas usb_wwan 20480 1 option uvcvideo 86016 0 video 45056 2 eeepc_laptop,i915 videobuf2_core 40960 2 uvcvideo,videobuf2_v4l2 videobuf2_memops 16384 1 videobuf2_vmalloc videobuf2_v4l2 24576 1 uvcvideo videobuf2_vmalloc 16384 1 uvcvideo videodev 159744 3 uvcvideo,videobuf2_core,videobuf2_v4l2 x_tables 28672 15 xt_LOG,ipt_REJECT,xt_pkttype,ip_tables,iptable_filter,xt_tcpudp,iptable_raw,xt_limit,ip6t_REJECT,ip6table_mangle,ip6table_filter,xt_CT,ip6table_raw,xt_conntrack,ip6_tables xt_conntrack 16384 6 xt_CT 16384 4 xt_limit 16384 10 xt_LOG 16384 10 xt_pkttype 16384 4 xt_tcpudp 16384 3 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

2630

Age (days ago)

2637

Last active (days ago)

List overview

Download

9 comments

6 participants

participants (6)

Axel Braun
Axel Braun
Axel Braun
Carlos E. R.
Oliver Neukum
Patrick Shanahan

[opensuse-factory] how to debug hibernation issue

tags

participants (6)