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
Created attachment 1655766 [details] messages after running systemctl hibernate
Created attachment 1655767 [details] messages after starting up hibernated machine
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
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.
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.
Interesting. If that'd proves to be case here too, then this will be some dracut issue.
Tried Frantisek's workaround, it fixes the issue, thanks! Any reason why 'resume' module isn't added to initrd by default?
The dracut resume module is pulled in, if ``` $ cat /sys/power/resume ``` does *not* output 0:0
That makes the whole thing rather brittle. Can it be pulled in unconditionally (by default)?
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
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.
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 ...
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
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 ----------|
One more fix: add white space around parameter: sudo echo 'add_dracutmodules+=" resume "' > /etc/dracut.conf.d/99-fix-resume.conf
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.
*** Bug 1842279 has been marked as a duplicate of this bug. ***
*** Bug 1798816 has been marked as a duplicate of this bug. ***
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.
*** Bug 2028195 has been marked as a duplicate of this bug. ***
*** Bug 1950190 has been marked as a duplicate of this bug. ***
*** Bug 1982641 has been marked as a duplicate of this bug. ***
The Comment 15 fix is still needed also for freshly installed F35.
*** Bug 1980090 has been marked as a duplicate of this bug. ***
*** Bug 2060501 has been marked as a duplicate of this bug. ***
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.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
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.
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.