Bugzilla – Bug 1165946
Failed to hibernate system via logind: Not enough swap space for hibernation
Last modified: 2020-04-17 14:49:59 UTC
Created attachment 832132 [details] y2logs New installation of TW on an empty disk. Swap partition is 16,4GB for 16GB of RAM Gerät Anfang Ende Sektoren Größe Typ /dev/nvme0n1p1 2048 1026047 1024000 500M EFI-System /dev/nvme0n1p2 1026048 1965973503 1964947456 937G Linux-Dateisystem /dev/nvme0n1p3 1965973504 2000409230 34435727 16,4G Linux Swap Root partition is encrypted Right after installation I did a couple of tests and hibernation worked. Afterwards I installed nvidia drivers. My impression is that since then hibernation is not working any more: X1E:/home/test # systemctl hibernate Failed to hibernate system via logind: Not enough swap space for hibernation Only standby (suspend to RAM) is possible
I recently experienced the same issue, which is solved for me by kernel 5.5.8 from the kernel stable repo. In fact, it contains: commit 3d6cf5c75ea54d338df3d89f2da56b98d4812011 Author: Chao Yu <chao@kernel.org> Date: Fri Dec 27 18:44:56 2019 +0800 f2fs: fix to add swap extent correctly commit 3e5e479a39ce9ed60cd63f7565cc1d9da77c2a4e upstream.
With the 5.6.3 series from Kernel:stable I am loosing from time to time "hibernation", i.e., I get > systemctl hibernate Failed to hibernate system via logind: Not enough swap space for hibernation even though there should be almost 4 GB swap available. > cat /etc/fstab UUID=084e4791-ca1c-44f3-86df-0e33c8b4fc81 / ext4 defaults 0 1 UUID=383e7b48-c1d2-4fef-8f2e-75b3a26a38c8 /home xfs defaults 0 0 UUID=b53752b8-7e3d-4c17-8fcb-73d112c702cf swap swap defaults 0 0 > cat /boot/grub2/grub.cfg |grep resume linux /boot/vmlinuz-5.6.3-2.g5b340fd-default root=UUID=084e4791-ca1c-44f3-86df-0e33c8b4fc81 resume=/dev/disk/by-uuid/b53752b8-7e3d-4c17-8fcb-73d112c702cf splash=silent quiet showopts mitigations=auto However, it seems that swap (sda7) is not mounted (correctly): > lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk ├─sda1 8:1 0 3,5G 0 part ├─sda2 8:2 0 100M 0 part ├─sda3 8:3 0 97,7G 0 part ├─sda4 8:4 0 1K 0 part ├─sda5 8:5 0 40G 0 part / ├─sda6 8:6 0 320,8G 0 part /home └─sda7 8:7 0 3,7G 0 part Any idea? Thx.
It is unclear to me whether "no swap" is a kernel and/or a systemd issue: > sudo journalctl -b | grep swap Apr 13 10:16:28 gropius systemd[1]: Activating swap /dev/disk/by-uuid/b53752b8-7e3d-4c17-8fcb-73d112c702cf... Apr 13 10:16:28 gropius systemd[1]: Activated swap /dev/disk/by-uuid/b53752b8-7e3d-4c17-8fcb-73d112c702cf. Apr 13 10:16:28 gropius kernel: Adding 3897364k swap on /dev/sda7. Priority:-2 extents:1 across:3897364k FS Apr 13 10:16:43 gropius systemd[1]: Deactivating swap /dev/disk/by-uuid/b53752b8-7e3d-4c17-8fcb-73d112c702cf... Apr 13 10:16:43 gropius systemd[1]: dev-sda7.swap: Succeeded. Apr 13 10:16:43 gropius systemd[1]: Deactivated swap /dev/sda7. Apr 13 10:16:43 gropius systemd[1]: dev-disk-by\x2duuid-b53752b8\x2d7e3d\x2d4c17\x2d8fcb\x2d73d112c702cf.swap: Succeeded. Apr 13 10:16:43 gropius systemd[1]: Deactivated swap /dev/disk/by-uuid/b53752b8-7e3d-4c17-8fcb-73d112c702cf.
Could you attach dmesg output after failed hibernation?
As I have changed the setup of my system completely I do not experience that issue at the moment Frank - can you add logs?
Created attachment 835712 [details] Output of dmesg for the case "failed hibernation" (In reply to Jiri Slaby from comment #4) > Could you attach dmesg output after failed hibernation? There you are. By the way, "swapon" gives nothing (cf. comment 2)
(In reply to Frank Kruger from comment #6) > Created attachment 835712 [details] > Output of dmesg for the case "failed hibernation" Thanks, the kernel did not even try to hibernate, so I suspect systemd did not even attempt to ask kernel.
(In reply to Frank Kruger from comment #2) > However, it seems that swap (sda7) is not mounted (correctly): Can you try to activate this swap manually and see whether it fixes your issue with hibernation ?
(In reply to Franck Bui from comment #8) > (In reply to Frank Kruger from comment #2) > > However, it seems that swap (sda7) is not mounted (correctly): > > Can you try to activate this swap manually and see whether it fixes your > issue with hibernation ? After 'sudo swapon -all' the swap partition is activated and hibernation works as expexted.
Then your issue boils down to figure out why the swap is deactivated in your case. Can you try to reboot with debug logs enabled (append "printk.devkmsg=on debug" to the kernel command line), make sure that the swap is inactive and attach the output of "journalctl -b -o short-monotonic" ? Thanks.
Created attachment 835843 [details] Debug Systemd No Swap (In reply to Franck Bui from comment #10) > Then your issue boils down to figure out why the swap is deactivated in your > case. > > Can you try to reboot with debug logs enabled (append "printk.devkmsg=on > debug" to the kernel command line), make sure that the swap is inactive and > attach the output of "journalctl -b -o short-monotonic" ? There you go, the output with deactivated swap.
Can you try to uninstall btrfsmaintenance package and see it that helps ?
(In reply to Franck Bui from comment #12) > Can you try to uninstall btrfsmaintenance package and see it that helps ? After uninstalling the package btrfsmaintance the swap partition is always activated automatically, as expected, and thus hibernation works fine (for kernels 5.6.3 and 5.6.4).
Then it's a duplicate of bsc#1137373. Can you please report your case back to upstream: https://github.com/systemd/systemd/issues/12953 ? It might help making upstream considering this issue as important. Meanwhile, if you don't have any btrfs file systems on your setup, you can keep btrfsmaintance package uninstalled. I don't know the reason why this package is always installed... Also I opened bsc#1165780 in order to improve btrfsmaintance which should mitigate the issue you're facing. *** This bug has been marked as a duplicate of bug 1137373 ***
(In reply to Franck Bui from comment #14) > Then it's a duplicate of bsc#1137373. > > > Meanwhile, if you don't have any btrfs file systems on your setup, you can > keep btrfsmaintance package uninstalled. I don't know the reason why this > package is always installed... This is a long story and due to the packkage btrfsprogs with "recommends btrfsmaintenance", even though btrfs is not used (see, e.g., bug 1145650 and bug 1124823). Unfortunately, the corresponding request to change this was declined 8 months ago: https://build.opensuse.org/request/show/697571. If you could do somthing, I would appreciate it.
It looks like this has been addressed eventually, see https://bugzilla.suse.com/show_bug.cgi?id=1124823#c21 ;)