Hibernation doesn’t work

[Musyanon 0]

Hello everyone,

 

I have install DSM on my Qnap TS559 pro+,
all work without problem except the hibernation.

 

I have the problem with 6.2.3 and I have downgrade to 6.2.2 but same problem.

 

Anyone know how can I resolve the problem ?

[Musyanon 0]

Finaly it work in 6.2.2, I have set the setting to 10 minutes, but it take more like 15 minutes to go hibernation....

Edited September 11, 2020 by Musyanon

[Mai_Mai 1]

Hello Musyanon.

 

Great to hear you recovered hibernation in DSM 6.2.2.

 

I consider downgrading form 6.2.3 to 6.2.2 too.

 

Can you describe the steps you followed to successfully downgrade ?

I fear to loose my data and parameters and I didn't found an actual how-to.

Edited October 4, 2020 by Mai_Mai
typo

[Musyanon 0]

Sorry, I have do a clean install without data...

You will need create a backup.

[Mai_Mai 1]

Thanks for the feedback.

 

I can't loose all my data so I will not do as you did.

And I'm not enough confident to apply the tutorial I found in the forum.

 

I stop the NAS manually waiting for a fix.

 

 

[IG-88 852]

4 hours ago, Mai_Mai said:

I can't loose all my data so I will not do as you did.

without a backup a are closer to that as you might think, there are some people here that had btrfs trouble after disks failing in a raid, you might see problems better with btrfs but the data are not safer then with ext4

when you can't make a backup of all data then structure them in a way that you can do a backup of the most important data like photos, documents, that's usually only a fraction like 1-4 TB instead of 20TB

 

for testing if 6.2.2 solves your problems you can just unplug your usb and all the disk, take a new usb and hdd (any size is ok) and install 6.2.2 using these two items

you can switch at any time between these two independent sets of usb and disk(s)

 

one of the problems with 6.2.3 is that we don't have kernel source (and until 3 days ago not even the kernel config used for compiling the kernel of 6.2.3) and we don't know how synology compensated for the problems it had before 6.2.2, fact is they reverted these changes (kernel config for pcie power management) from 6.2.2 when going to 6.2.3 and maybe they did some changes in the kernel source we don't have and that's causing problems - but thats just guessing

 

in this thread there is no mention of loader and dsm type used, i guess its 1.03b with 3615/17 but at least be precise when trying to document a problem

also what kind of hibernation is it, the one i know is just disk hibernation, when disks spin down after a defined period

[flyride 644]

5 hours ago, IG-88 said:

also what kind of hibernation is it, the one i know is just disk hibernation, when disks spin down after a defined period

 

Disk hibernation/spindown is what folks are concerned about with 6.2.3. There are a lot of reasons it may not be working, but mostly log messages written recurrently to /var/log due to hardware status failures resulting from non-Synology hardware.  That's one of the reasons I've posted on some filtering of smart and scemd errors, but there are many errors and they differ depending on the platform you have installed. Unfortunately not a simple or single solution works for all.

[Mai_Mai 1]

Il y a 13 heures, IG-88 a dit :

in this thread there is no mention of loader and dsm type used, i guess its 1.03b with 3615/17 but at least be precise when trying to document a problem

also what kind of hibernation is it, the one i know is just disk hibernation, when disks spin down after a defined period

 

I'm on june's loader 1.03b with Ds315xs. My NAS is an HP  microserver gen8 using DSM 6.2.3-25426-2 and an additional Intel NIC.

 

I'm using a script to start the nas with WOL function and I appreciate it shuts off automatically after some time of HDD inactivity.

 

I' didn't try yet the workaround suggested by flyride. 

 

[Mai_Mai 1]

Just a quick feedback to tell I managed to restore hibernation with the workaround found on an another post :

 

 

 

I accessed to my NAS with Putty ;  edit scemd.conf in  /etc.defaults/syslog-ng/patterndb.d/ using vi and replace  :

 

destination d_scemd { file("/var/log/scemd.log"); };

 

with :

 

destination d_scemd { file("/dev/null"); };

 

Reboot and that's all !

[Musyanon 0]

Le 12/11/2020 à 21:08, Mai_Mai a dit :

Just a quick feedback to tell I managed to restore hibernation with the workaround found on an another post :

 

 

 

I accessed to my NAS with Putty ;  edit scemd.conf in  /etc.defaults/syslog-ng/patterndb.d/ using vi and replace  :

 

destination d_scemd { file("/var/log/scemd.log"); };

 

with :

 

destination d_scemd { file("/dev/null"); };

 

Reboot and that's all !

 

Thanks, also works !

[boris blank 0]

My thanks to Mai_Mai, that worked for me too!

[nadiva 4]

this is one frustrating feature i could never fix. There's no hibernation on my Ds918 image, drives spin up as soon as i spin them down manually (hdparm). Meanwhile electricity costs explode, my electricity provider bankrupted, and the drives which are needed for 1hour a day, make noise reminding me of this every day, just like the main fan makes horrid noise (unfixable issue on HP Gen10 thanks to weird fan setup, i've burnt one server playing with cables/adapters/regulators).

surprising to see someone can spin down disks, i'd believe a complete hibernation is possible (not in my case), but how you can spin down disks on live system with / mapped to the RAID1 (md0)?

the good ole' trick with installing on one drive, then add raid drives doesn't work as DSM will expand on all drives as soon as it detects them.

i have 2 standalone drives and 4 RAID drives, so i could still have a "system RAID" active if i shrinked the system RAID(+swap) from 6 to 2 hdds. but i worry DSM would complain. i'd have to also create a dummy allocation there to make sure no RAID fits.

the fix above didn't work. i remember very well drives couldn't spin down on an empty installation either.

all i am reduced to now is read the bad advices how running drives 24/7 is 'healthy' (a hoax that spreads on internet like "BTRFS is not good for RAID").