Bug 1795422 - System image not restored after hibernation
Summary: System image not restored after hibernation
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 37
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1798816 1842279 1950190 1982641 2028195 2060501 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-27 22:40 UTC by Tomas
Modified: 2023-12-05 20:59 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-12-05 20:59:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
messages after running systemctl hibernate (2.64 KB, text/plain)
2020-01-27 22:42 UTC, Tomas
no flags Details
messages after starting up hibernated machine (89.95 KB, text/plain)
2020-01-27 22:43 UTC, Tomas
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github dracutdevs dracut issues 924 0 None open Resume does not work (potential #cee5853 regression?) 2021-04-13 08:51:21 UTC

Description Tomas 2020-01-27 22:40:51 UTC
Description of problem:

Starting a machine after running "systemctl hibernate" noticed that disk image that was created ([  552.042240] PM: Wrote 571104 kbytes in 4.20 seconds (135.97 MB/s) ) is not used hence system appears like it just started

Version-Release number of selected component (if applicable):

systemd 244 (v244.1-2.fc32)

How reproducible:

run: systemctl hibernate

Steps to Reproduce:

screen -d -m yes
screen -list
systemctl hibernate
start machine and log in
scrren -list


Actual results:

No Sockets found in /run/screen/S-root.


Expected results:

There is a screen on:
	808..uola-qa	(Detached)
1 Socket in /run/screen/S-root.


Additional info:

To debug I've added a script to /usr/lib/systemd/system-sleep/run that handles "pre" and "post" args writing a log.

when running systemctl suspend, both pre and post are executed:

Tue 28 Jan 2020 08:36:58 AM AEST suspending...
Tue 28 Jan 2020 08:37:00 AM AEST resuming...

when running systemctl hibernate, only pre is executed

Tue 28 Jan 2020 08:38:07 AM AEST suspending...

also uptime after resuiming the system:
# uptime
 08:40:30 up 0 min,  1 user,  load average: 0.04, 0.01, 0.00

Comment 1 Tomas 2020-01-27 22:42:13 UTC
Created attachment 1655766 [details]
messages after running systemctl hibernate

Comment 2 Tomas 2020-01-27 22:43:00 UTC
Created attachment 1655767 [details]
messages after starting up hibernated machine

Comment 3 Ben Cotton 2020-02-11 17:24:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 4 Zbigniew Jędrzejewski-Szmek 2020-04-16 09:45:11 UTC
I see you have resume= configured on the kernel command line, so resume should work.
Can you install systemd-tests and run 'sudo /usr/lib/systemd/tests/test-sleep' and paste the output here?
It prints what systemd thinks the hibernation partition should be and other details.

Comment 5 Frantisek Sumsal 2020-04-16 10:09:43 UTC
I had the exact same issue on my F31 and F32 installation and after some digging I noticed that my initrd is, for whatever reason, built without the `resume` module, which is responsible for parsing of the `resume=` argument from kernel cmdline.

You can check it by calling:
```
$ sudo lsinitrd -m | grep -E '^resume$'
```

if the output is empty, your initrd is built without the `resume` module.

You can, temporarily, fix this with:
```
$ sudo dracut -fv -a resume
## Sanity check
$ sudo lsinitrd -m | grep -E '^resume$'
resume
```

After this, try to hibernate & resume the system. If it works, you can make the fix permanent with:
```
$ sudo echo 'add_dracutmodules+="resume" > /etc/dracut.conf.d/99-fix-resume.conf
$ sudo dracut -fv
```

Not sure if it's a proper solution, but hibernating/resuming works for me since then.

Comment 6 Zbigniew Jędrzejewski-Szmek 2020-04-16 11:05:24 UTC
Interesting. If that'd proves to be case here too, then this will be some dracut issue.

Comment 7 Tomas 2020-04-22 01:36:55 UTC
Tried Frantisek's workaround, it fixes the issue, thanks!
Any reason why 'resume' module isn't added to initrd by default?

Comment 8 Harald Hoyer 2020-04-24 11:44:59 UTC
The dracut resume module is pulled in, if 
```
$ cat /sys/power/resume
```
does *not* output 0:0

Comment 9 Zbigniew Jędrzejewski-Szmek 2020-04-24 12:20:29 UTC
That makes the whole thing rather brittle. Can it be pulled in unconditionally (by default)?

Comment 10 Hansel Gaete 2020-06-05 12:22:50 UTC
Thanks Frantisek Sumsal,

work for my laptop

Linux --- 5.6.15-300.fc32.x86_64 #1 SMP Fri May 29 14:23:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Comment 11 Robin Gierse 2020-06-17 17:36:17 UTC
Same problem here. F32, fresh install. I think at least the general possibility should be there to use hibernation by default. Especially as it took me three days to make sure I was not getting anything wrong before I found this bug report. No one is forced to use it, but I think the steps outlined above should be necessary every time you set up Fedora.

Comment 12 zrzut01 2020-07-04 17:45:27 UTC
Same problem here. F32, fresh install with use of 'Fedora-Workstation-Live-x86_64-32-1.6.iso'. This is huge fail in my opinion especially that on fresh installation of F31 it works properly. Please add it to known issues/workarounds/commonbugs. I can see Support->Common Bugs on main web page of getfedora.org. It should definitely be there as workaround if Fedora team is not going to fix it in official installation media. But IMHO they should ...

Comment 13 Ken Smith 2020-07-13 11:14:55 UTC
I have two laptops whose suspend behaviour is different with FC32. I thought this data point might be useful for tracing this anomaly. 

A newer Dell that started with FC29 has been upgraded through to FC32 and suspend works fine. And an older Acer that is a recent clean install of FC32 where suspend fails as described in this bug report. 

The workaround described here does not fix the Acer. 

The Acer does not have resume in response to "lsinitrd -m" but the Dell does. Has dracut behaved differently as the Dell has EFI and the Acer doesn't? Or this this difference due to the Dell starting out as FC29?



This is the ACER's inxi

System:    Host: kenslt3-fcore Kernel: 5.7.7-200.fc32.x86_64 x86_64 bits: 64 Console: tty 3 
           Distro: Fedora release 32 (Thirty Two) 
Machine:   Type: Laptop System: Acer product: Extensa 5220 v: 0100 serial: LXE880C031818047212000 
           Mobo: Acer model: Columbia v: Rev serial: LXE880C031818047212000 BIOS: Phoenix v: 1.34 date: 04/15/2008 
Battery:   ID-1: BAT0 charge: 41.5 Wh condition: 41.5/65.1 Wh (64%) 
CPU:       Topology: Dual Core model: Intel Core2 Duo T7800 bits: 64 type: MCP L2 cache: 4096 KiB 
           Speed: 1157 MHz min/max: 800/2601 MHz Core speeds (MHz): 1: 967 2: 986 
Graphics:  Device-1: Intel Mobile GM965/GL960 Integrated Graphics driver: i915 v: kernel 
           Device-2: Suyin Acer CrystalEye Webcam type: USB driver: uvcvideo 
           Display: server: Fedora Project X.org 1.20.8 driver: i915 note: display driver n/a resolution: 1280x800~60Hz 
           OpenGL: renderer: Mesa DRI Intel 965GM (CL) v: 2.1 Mesa 20.1.2 
Audio:     Device-1: Intel 82801H HD Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.7.7-200.fc32.x86_64 
Network:   Device-1: Broadcom and subsidiaries NetLink BCM5787M Gigabit Ethernet PCI Express driver: tg3 
           IF: enp2s0 state: down mac: 00:1d:72:2e:17:29 
           Device-2: Intel PRO/Wireless 3945ABG [Golan] Network driver: iwl3945 
           IF: wlp4s0 state: up mac: 00:1c:bf:18:77:c3 
           IF-ID-1: virbr0 state: down mac: 52:54:00:1e:37:9c 
           IF-ID-2: virbr0-nic state: down mac: 52:54:00:1e:37:9c 
Drives:    Local Storage: total: 931.51 GiB used: 14.22 GiB (1.5%) 
           ID-1: /dev/sda vendor: HGST (Hitachi) model: HTS721010A9E630 size: 931.51 GiB 
Partition: ID-1: / size: 47.89 GiB used: 14.22 GiB (29.7%) fs: ext4 dev: /dev/sda10 
Swap:      Alert: No Swap data was found. 
Sensors:   System Temperatures: cpu: 52.0 C mobo: 48.0 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 210 Uptime: 2h 23m Memory: 2.91 GiB used: 1.47 GiB (50.7%) Shell: bash inxi: 3.1.03 

And this is the Dell

System:    Host: localhost.localdomain Kernel: 5.7.8-200.fc32.x86_64 x86_64 bits: 64 Console: tty 2 
           Distro: Fedora release 32 (Thirty Two) 
Machine:   Type: Laptop System: Dell product: Latitude E7450 v: 01  
           Mobo: Dell model: 01TXGV v: A00  UEFI [Legacy]: Dell v: A00 date: 10/24/2014 
Battery:   ID-1: BAT0 charge: 52.0 Wh condition: 52.0/56.2 Wh (92%) 
CPU:       Topology: Dual Core model: Intel Core i5-5200U bits: 64 type: MT MCP L2 cache: 3072 KiB 
           Speed: 798 MHz min/max: 500/2700 MHz Core speeds (MHz): 1: 798 2: 798 3: 798 4: 804 
Graphics:  Device-1: Intel HD Graphics 5500 driver: i915 v: kernel 
           Device-2: Microdia type: USB driver: uvcvideo 
           Display: server: X.org 1.20.8 driver: modesetting unloaded: fbdev,vesa tty: 133x34 
           Message: Advanced graphics data unavailable in console for root. 
Audio:     Device-1: Intel Broadwell-U Audio driver: snd_hda_intel 
           Device-2: Intel Wildcat Point-LP High Definition Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.7.8-200.fc32.x86_64 
Network:   Device-1: Intel Ethernet I218-LM driver: e1000e 
           IF: eno1 state: down mac: 34:e6:d7:35:24:c7 
           Device-2: Broadcom and subsidiaries BCM4352 802.11ac Wireless Network Adapter driver: wl 
           IF: wlp2s0 state: up mac: ac:d1:b8:bf:3b:6f 
           IF-ID-1: virbr0 state: down mac: 52:54:00:88:fa:0d 
           IF-ID-2: virbr0-nic state: down mac: 52:54:00:88:fa:0d 
Drives:    Local Storage: total: 232.89 GiB used: 46.59 GiB (20.0%) 
           ID-1: /dev/sda vendor: Crucial model: CT250MX200SSD1 size: 232.89 GiB 
RAID:      Hardware-1: Intel 82801 Mobile SATA Controller [RAID mode] driver: ahci 
Partition: ID-1: / size: 48.97 GiB used: 13.89 GiB (28.4%) fs: ext4 dev: /dev/dm-0 
           ID-2: /boot size: 975.9 MiB used: 258.5 MiB (26.5%) fs: ext4 dev: /dev/sda1 
           ID-3: /home size: 174.47 GiB used: 32.43 GiB (18.6%) fs: ext4 dev: /dev/dm-2 
Swap:      ID-1: swap-1 type: partition size: 3.62 GiB used: 16.0 MiB (0.4%) dev: /dev/dm-1 
Sensors:   System Temperatures: cpu: 43.0 C mobo: 36.0 C sodimm: 31.0 C 
           Fan Speeds (RPM): cpu: 0 
Info:      Processes: 236 Uptime: 21h 56m Memory: 3.47 GiB used: 1.38 GiB (39.6%) Init: systemd runlevel: 5 Shell: bash 
           inxi: 3.1.03 

As a further, more confusing, data point I have a desktop machine with a clean FC32 install, that has a old, non-efi MB where this fix does fix the suspend issue. This is its inxi

System:    Host: localhost.localdomain Kernel: 5.7.7-200.fc32.x86_64 x86_64 bits: 64 Console: tty 0 
           Distro: Fedora release 32 (Thirty Two) 
Machine:   Type: Desktop Mobo: Gigabyte model: 965P-DS3 serial: N/A BIOS: Award v: F13 date: 07/17/2008 
CPU:       Topology: Dual Core model: Intel Core2 6300 bits: 64 type: MCP L2 cache: 2048 KiB 
           Speed: 1600 MHz min/max: 1600/1867 MHz Core speeds (MHz): 1: 1600 2: 1600 
Graphics:  Device-1: NVIDIA GK208B [GeForce GT 710] driver: nouveau v: kernel 
           Device-2: Conexant Systems CX23885 PCI Video and Audio Decoder driver: cx23885 v: 0.0.4 
           Display: server: X.org 1.20.8 driver: cx23885 note: display driver n/a tty: 133x34 
           Message: Advanced graphics data unavailable in console for root. 
Audio:     Device-1: Intel 82801H HD Audio driver: snd_hda_intel 
           Device-2: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel 
           Device-3: TBS DVB Tuner PCIe Card driver: TBSECP3 driver 
           Device-4: Conexant Systems CX23885 PCI Video and Audio Decoder driver: cx23885 
           Sound Server: ALSA v: k5.7.7-200.fc32.x86_64 
Network:   Device-1: Marvell 88E8053 PCI-E Gigabit Ethernet driver: sky2 
           IF: enp5s0 state: up speed: 1000 Mbps duplex: full mac: 00:16:e6:82:91:79 
           IF-ID-1: virbr0 state: down mac: 52:54:00:a6:f2:e4 
           IF-ID-2: virbr0-nic state: down mac: 52:54:00:a6:f2:e4 
Drives:    Local Storage: total: 5.46 TiB used: 53.03 GiB (0.9%) 
           ID-1: /dev/sda vendor: Western Digital model: WD30EFRX-68EUZN0 size: 2.73 TiB 
           ID-2: /dev/sdb vendor: Western Digital model: WD30EFRX-68EUZN0 size: 2.73 TiB 
RAID:      Device-1: md0 type: mdraid status: active raid: mirror report: 2/2 UU Components: online: sdb4~c1 sda4~c0 
Partition: ID-1: / size: 57.42 GiB used: 52.76 GiB (91.9%) fs: ext4 dev: /dev/dm-0 
           ID-2: /boot size: 1.80 GiB used: 275.2 MiB (14.9%) fs: ext4 dev: /dev/sda2 
Swap:      ID-1: swap-1 type: partition size: 9.31 GiB used: 0 KiB (0.0%) dev: /dev/sda3 
Sensors:   System Temperatures: cpu: 77.0 C mobo: N/A gpu: nouveau temp: 43 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 187 Uptime: 5m Memory: 7.77 GiB used: 732.6 MiB (9.2%) Init: systemd runlevel: 5 Shell: bash 
           inxi: 3.1.03

Comment 14 digger vermont 2020-10-29 23:25:04 UTC
Thanks Frantisek Sumsal!

Except for the addition of a semi-quote, this works for me on a new Lenovo Carbon X1 Gen 8 shipped with Fedora 32 and upgraded to F33
One would hope Lenovo would have already added the module.

sudo echo 'add_dracutmodules+="resume"' > /etc/dracut.conf.d/99-fix-resume.conf
                                      ^
                 semi-quote ----------|

Comment 15 Milan Kerslager 2021-01-30 19:27:36 UTC
One more fix: add white space around parameter:

sudo echo 'add_dracutmodules+=" resume "' > /etc/dracut.conf.d/99-fix-resume.conf

Comment 16 Milan Kerslager 2021-01-30 19:36:15 UTC
On my F33 I had 0:0 in the output of: cat /sys/power/resume
Once I manually add resume module to the dracut configuration as written above, resume started to work.

Comment 17 David Tardon 2021-04-13 08:55:05 UTC
*** Bug 1842279 has been marked as a duplicate of this bug. ***

Comment 18 David Tardon 2021-04-13 09:01:59 UTC
*** Bug 1798816 has been marked as a duplicate of this bug. ***

Comment 19 Fedora Program Management 2021-04-29 16:51:30 UTC
This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 20 David Tardon 2021-12-06 09:19:21 UTC
*** Bug 2028195 has been marked as a duplicate of this bug. ***

Comment 21 David Tardon 2021-12-06 09:34:01 UTC
*** Bug 1950190 has been marked as a duplicate of this bug. ***

Comment 22 David Tardon 2021-12-06 09:35:17 UTC
*** Bug 1982641 has been marked as a duplicate of this bug. ***

Comment 23 Jan Kratochvil 2021-12-06 09:43:21 UTC
The Comment 15 fix is still needed also for freshly installed F35.

Comment 24 David Tardon 2022-04-12 11:16:31 UTC
*** Bug 1980090 has been marked as a duplicate of this bug. ***

Comment 25 David Tardon 2022-04-12 11:17:50 UTC
*** Bug 2060501 has been marked as a duplicate of this bug. ***

Comment 26 Ben Cotton 2022-05-12 16:34:57 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 27 Ben Cotton 2022-08-09 13:10:45 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 28 Aoife Moloney 2023-11-23 00:02:47 UTC
This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 29 Aoife Moloney 2023-12-05 20:59:05 UTC
Fedora Linux 37 entered end-of-life (EOL) status on None.

Fedora Linux 37 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.