Deduplication configuration still not showing up for HDDs

[Msprg]

I'm running DSM as a Proxmox VM with passed-trough SATA controller for the drives.

I have run both enable deduplication with --hdd parameter and hdd_db script. Rebooted multiple times. Everything is healthy, performance analysis is enabled, and I've waited more than 10 minutes for the menu to show up. Like #79 but I still can't get it to work.

Any ideas about what I'm missing??

[007revad]

It is looking like it's a an issue with virtual disks. Xpenology, proxmox and virtual disks are all beyond my level of knowledge.

[Msprg]

Definitely not. As I've mentioned, the sata controller is passed through, meaning that the drives are communicating with DSM exactly as they would in a real bare metal hardware DSM system.

As far as virtual disks are concerned. Actually, the deduplication for those was ironically easily available even before running your scripts, despite me not needing it.

[Msprg]

Would you mind sending me your patched StorageManager 1.0.0-00502 storage_component.js file to compare it to mine?

[Msprg]

@007revad There's a different js file that's being sent to the DSM web clients than the one your script is modifying, or something like that. Because, even if the &&e.dedup_info.show_config_btn is deleted in the file correctly, the browser is still getting storage_panel.js that still contains the check. I have 100% confirmed that that's the culprit by using proxy and swapping the js Synology is sending with the modified js. And the deduplication menu was available right there and then.

It's not browser cache, and I have rebooted Synology - multiple times, and cold booted it as well.

Now I can't say what to do now. Maybe there's another caching going on in the Synology itself or something? I really don't feel like grepping entire file system just to find where is the other file / string hiding, but that's my last resort for now.
Let me know if you happen to have any ideas~!

[007revad]

After a reboot is the &&e.dedup_info.show_config_btn still deleted?

I just searched DSM 7.2.2 update 2 for files named storage_panel.js on a DS720+ and only found 2 storage_panel.js files

storage_panel.js               <-- the edited file
storage_panel.js.1.0.0-00502   <-- backup of the original file

I wonder if DSM is loading the backup storage_panel.js.1.0.0-00502 file as storage_panel.js. You could try moving, renaming or deleting storage_panel.js.1.0.0-00502.

[Msprg]

root@DSM1:/usr/local/packages/@appstore/StorageManager/ui# sha256sum storage_panel.js*
bdab05da7e550fd4696e9e9f7a54694d40ee71f1711799ec64078a7a601d0a94  storage_panel.js
bdab05da7e550fd4696e9e9f7a54694d40ee71f1711799ec64078a7a601d0a94  storage_panel.js.1.0.0-00502
9dec4942926cc8ec184c9575aa5d35cbb1ab10f7f6888d881b4c0f0ea5405e03  storage_panel.js.gz
cbf8f3709fcc43f1e5cc360e726bbb6e739e8176d3fd52b41f237a9400694280  storage_panel.js.gz.bak

I removed the check, and made both files the same. There has to be some other place where it's pulling it from still…

And btw, yes, the modifications do survive reboots.

[Msprg]

Oh, and maybe this will help, this is the file that Synology is sending despite having the files above modified: storage_panel_sentBySyno.zip

[007revad]

And btw, yes, the modifications do survive reboots.

Do you have syno_enable_dedupe.sh scheduled?

My real Synology NAS don't have the storage_panel.js.gz (or storage_panel.js.gz.bak) files. I assume they are created by the xpe loader. Does the storage-panel.js in storage_panel.js.gz contain &&e.dedup_info.show_config_btn?

I suspect what is happening is your xpe loader, or trcp-addons etc, is recreating storage-panel.js during the junior boot stage and then syno_enable_dedupe is editing it. But where the ui is loading an unedited copy from is a mystery.

A quick look at storagepanel.sh and install.sh shows they are creating the gzipped copy of storage-manager.js

[Msprg]

Do you have syno_enable_dedupe.sh scheduled?

I don't.

My real Synology NAS don't have the storage_panel.js.gz (or storage_panel.js.gz.bak) files.

Oh, I didn't know that!
I've tried to modify the archives, and it seems to have worked!
I think they're there because the DSM loader allows choosing things such as HDD bays graphics etc., so I guess it's achieving that by modifying the storage_panel.js as well.

[007revad]

I've tried to modify the archives, and it seems to have worked!

If you reboot does the storage_panel.js.gz still contain your edits?

I might change the script to delete the existing storage_panel.js.gz and gzip storage_panel.js

But before I do that can you provide a zip file containing everything in /usr/local/packages/@appstore/StorageManager/ui

[Msprg]

If you reboot does the storage_panel.js.gz still contain your edits?

So far, yes they do. However, I suspect that updates to the loader can easily break it / revert the changes.

But before I do that can you provide a zip file containing everything in /usr/local/packages/@appstore/StorageManager/ui

Sure can do. Here you go, should be in more-less unmodified (xpenology / loader) state:
StorageManagerui.tar.gz