OMV6 is Unable to sleep/standby

I couldn't get my drives to spindown with OMV 6 which works perfectly fine on OMV 4 and 5.

Quote from auanasgheps

extended the swap partition.

I'm curious regarding this issue and solution.

What was the original size of swap partition?

Was RAM size changed after installation?

Maybe a check should be added to UI given the results in issue https://github.com/openmediavault/openmediavault/issues/66

Quote from auanasgheps

install didn't go very smoothly

do you remember the kernel version that got installed? the linked picture would let me assume a 5.14 kernel (but only indirectly).

LTS kernels considered good are 5.10 and 5.15

the kernel version is visible in dashboard/system information or by CLI uname -a

Hello everyone, I am having a similar issue with putting OMV6 to sleep-hibernate-suspend (on my Intel NUC NUC7PJYHN with a Pentium Silver J5005 CPU) in order to wake it later via WOL.

Currently running latest OMV 6.9.16-1 booting from USB stick; RAM is 8GB; main data on the SATA drive (one partition) and using the Flash Memory plugin (seemingly running just fine since day one). BIOS settings are default, no deep-sleep set S4/S5 etc. and WoL works well (in terms of LAN port, BIOS etc.). Note: Per past tradition in OMV4 and OMV5, I have disabled the swap partition in /etc/fstab

1. When I run/send the command from my other computer:

ssh -i ~/.ssh/id_rsa root@192.168.1.200 sudo systemctl suspend

...the NUC goes to sleep, with the power LED breathing/pulsating. But when I press any key on the keyboard, its power button or send a WoL packet to wake it up, it goes into some bizarre freezing mode, no HDMI output (to see what is happening) and nothing happens at all (I did wait for some time, then was forced to hard-reset it so I can reboot again and do fsck etc.). Not sure what BIOS setting may prevent it from working correctly. By the way, RAM modules seem fine, had run MemTest86 in the past.

Note: On my other previous Intel NUC6CAYH running OMV6 (latest) remotely, this method works fine without issues... It has an Intel Celeron J3455 CPU, if that matters.

2. When I run/send this other command:

ssh -i ~/.ssh/id_rsa root@192.168.1.200 sudo systemctl hibernate

...the NUC takes some time (seems to write something to the SSD) but completely stops (hibernates) with no LED pulsating on the front. However, this works like 50% of the times, I need to reboot OMV to "refresh" its condition.

Note: I have tried with and without the swap file declared/enabled in /etc/fstab and have mixed results. I remember that when the swap file was enabled, and it did not hibernate, the error was to some "not enough space" and I read there in this thread about the need to make the swap partition larger etc. but haven't got into it yet.

I also see that there exists systemctl suspend-then-hibernate but never tried it, not sure how it behaves.

Not sure if it's related to BIOS, to the CPU and the OMV6 kernel, or the fact I boot from USB..., any ideas anyone? Thanks in advance.

Hi macom  ryecoaaron apologies to tag you, perhaps you could offer your insight and experience?

When sending the above systemctl command to this OMV6 via SSH, I see that it fails, and entering via root in CLI I get the following:

% systemctl list-units -all --state=failed

  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION
● systemd-hibernate.service loaded failed failed Hibernate

% systemctl status systemd-hibernate.service

● systemd-hibernate.service - Hibernate
     Loaded: loaded (/lib/systemd/system/systemd-hibernate.service; static)
     Active: failed (Result: exit-code) since Tue 2024-06-18 21:54:35 CEST; 4min 58s ago
       Docs: man:systemd-suspend.service(8)
    Process: 44546 ExecStart=/lib/systemd/systemd-sleep hibernate (code=exited, status=1/FAILURE)
   Main PID: 44546 (code=exited, status=1/FAILURE)
        CPU: 5.242s

% cat /var/log/syslog | grep -i sleep

Jun 18 08:30:50 qvo-nas cron-apt: CRON-APT SLEEP: 3330, Tue Jun 18 08:30:42 CEST 2024
Jun 18 21:53:52 qvo-nas systemd[1]: Reached target Sleep.
Jun 18 21:53:52 qvo-nas systemd-sleep[44546]: Suspending system...
Jun 18 21:54:34 qvo-nas kernel: [205456.901803] ACPI: PM: Preparing to enter system sleep state S4
Jun 18 21:54:34 qvo-nas kernel: [205456.920549] ACPI: PM: Waking up from system sleep state S4
Jun 18 21:54:34 qvo-nas systemd-sleep[44546]: Failed to suspend system. System resumed again: No space left on device
Jun 18 21:54:35 qvo-nas collectd[1074]: Not sleeping because the next interval is 31.092 seconds in the past!
Jun 18 21:54:35 qvo-nas systemd[1]: Stopped target Sleep.

For info, I have commented/disabled the swap partition of the USB boot stick in /etc/fstab as enabling it didn't really change the outcome in my tests. What is funny is that when I reboot OMV6, and send the hibernate command, it works... it's just after hours or days that it won't work again.

Here's some more logs, if they help?

% cat /var/log/debug

Jun 18 21:54:34 qvo-nas kernel: [205419.727398] PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]
Jun 18 21:54:34 qvo-nas kernel: [205419.727408] PM: hibernation: Marking nosave pages: [mem 0x0003f000-0x0003ffff]
Jun 18 21:54:34 qvo-nas kernel: [205419.727414] PM: hibernation: Marking nosave pages: [mem 0x00059000-0x00059fff]
Jun 18 21:54:34 qvo-nas kernel: [205419.727419] PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x000fffff]
Jun 18 21:54:34 qvo-nas kernel: [205419.727428] PM: hibernation: Marking nosave pages: [mem 0x10000000-0x12150fff]
Jun 18 21:54:34 qvo-nas kernel: [205419.727851] PM: hibernation: Marking nosave pages: [mem 0x73dbe000-0x73e1ffff]
Jun 18 21:54:34 qvo-nas kernel: [205419.727861] PM: hibernation: Marking nosave pages: [mem 0x773d0000-0x7a170fff]
Jun 18 21:54:34 qvo-nas kernel: [205419.728439] PM: hibernation: Marking nosave pages: [mem 0x7a565000-0x7a610fff]
Jun 18 21:54:34 qvo-nas kernel: [205419.728452] PM: hibernation: Marking nosave pages: [mem 0x7ac00000-0xffffffff]
Jun 18 21:54:34 qvo-nas kernel: [205419.746033] PM: hibernation: Basic memory bitmaps created
Jun 18 21:54:34 qvo-nas kernel: [205457.090926] PM: hibernation: Normal pages needed: 488422 + 1024, available pages: 1566459
Jun 18 21:54:34 qvo-nas kernel: [205461.180288] PM: hibernation: Basic memory bitmaps freed

% df -h /dev/sdb2
Filesystem      Size   Used  Avail.  Use%   Mounted on
/dev/sdb2        58G   5.3G    49G    10%   /

Although my USB stick is not ideal to save/dump memory or swapping etc. I am wondering where does this error "Failed to suspend system. System resumed again: No space left on device" comes from, it refers to the missing swap partition or the space on the boot partition itself?

Thank you, your time is appreciated.

P.S. The swap partition is the one created by the OMV6 installer i.e. 977M Linux "swap" and never touched/increased etc.

P.S. I rebooted the server and hibernate worked, as before... the question is for how long (without rebooting again) <shrug>

Maybe it is not sleepy or tired? Maybe it identifies as never having to?

LOL fbeye well the OMV NAS has to sleep... and conserve energy... and a few Euros in my pocket

Hi auanasgheps thanks for your tips. Indeed, on my USB installations the swap file is disabled as I wrote.

However, on my Intel NUC, putting to standby does go to sleep, I get breathing power LED but upon waking, it freezes (nothing on HDMI either to see) hence why I tried hibernate... but it doesn't make sense. If I reboot, the machine can hibernate. If I leave it for hours or days without rebooting, then hibernate fails...

Anyway booted on a parallel USB to PartedMagic, shrunk main OMV partition and expanded swap partition to a little over 4GB. Rebooted, all seems to have gone well. I have re-enabled the swap partition in /etc/fstab and did sudo swapoff -a; sudo swapon -a just in case (and see if there are errors) so time and use will tell if this was the reason. I will report back.

However, I read online that the "formula" for computing swap size is twice the amount of the system's RAM... not sure if this remains the case for OMV and why the 1GB partition is created with the installer, regardless of RAM detected on the system during installation

P.S. For info, the correct partition UUID is validated between /etc/initramfs-tools/conf.d/resume and /etc/fstab and swappiness and cache pressure remain default per OMV installation:

% cat /etc/initramfs-tools/conf.d/resume
and
% cat /etc/fstab

% free -k
               total        used        free      shared  buff/cache   available
Mem:         7705768      695648     4442684      812164     2567436     5888688
Swap:        4479996           0     4479996

% grep '^Swap' /proc/meminfo

SwapCached:            0 kB
SwapTotal:       4479996 kB
SwapFree:        4479996 kB

% cat /proc/sys/vm/swappiness
60

% cat /proc/sys/vm/vfs_cache_pressure
100

Thanks.