Donec Facilisis Lacinia


Let me clarify my post above. I don’t believe the command does anything because I don’t see labels defined on any of the remaining devices, so follows that they are probably not using labels at all. However, I just looked on my NAS and the “entware-ng” version of “blkid” produces the following:

root@WDMyCloudEX4100 root # blkid
/dev/dm-1: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/dm-0: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/md1: UUID="0ddbf58d-693a-4731-819d-2736d4a373e7"
/dev/loop1: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/sdd4: UUID="a084a048-6978-450e-a326-bd82ab81785a"
/dev/sdc4: UUID="cb05b2ed-2555-4ac0-a8c3-1fb38c952c10"
/dev/sdc2: UUID="0ddbf58d-693a-4731-819d-2736d4a373e7"
/dev/sdb4: UUID="35d44091-85fe-4f0a-8a0b-7f29d717c8da"
/dev/sdb2: UUID="5f42d319-6fb3-4ac0-b710-23292db2f778"
/dev/sda4: UUID="62e2a499-e3d8-4ce7-b67c-2b37a505fbcd"
/dev/ram0: UUID="42f62123-de52-447c-a5b9-335168f0f750"
/dev/mapper/docker-9:1-80347142-b0cf4a948d6e1744d31feab8a471a604cdc87583ff9b5d7fc676eed5e359f292: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"
/dev/mapper/docker-9:1-80347142-pool: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1"

Here is the results from the stock version of blkid::

root@WDMyCloudEX4100 / # /usr/local/modules/bin/blkid
/dev/ubi2_0: UUID="21e2b22d-facd-45c6-a6b5-d2c4ed2d9201" TYPE="ubifs"
/dev/ubi1_0: UUID="7f2ffc37-f41c-4db4-a6db-0916da6130dd" TYPE="ubifs"
/dev/ubi0_0: UUID="0a896697-098b-48b8-9a65-39cc54496495" TYPE="ubifs"
/dev/loop0: TYPE="squashfs"
/dev/loop1: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1" TYPE="ext4"
/dev/sda1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="62425411-2600-46ea-9c7f-50f41ace1ff7"
/dev/sda2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="ce102707-dba4-065a-64d7-ea9e44e1da5a" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="453fb6fb-9246-4773-b03e-4519b60f2b39"
/dev/sda4: UUID="62e2a499-e3d8-4ce7-b67c-2b37a505fbcd" TYPE="ext4"
/dev/sdb1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="64e425f3-c936-4301-8fe1-aaad5de10486"
/dev/sdb2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="18145e0e-44c5-5571-c750-f01e6b8832e2" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="12426d19-8608-4cea-8f7d-f9299cc95d29"
/dev/sdb4: UUID="35d44091-85fe-4f0a-8a0b-7f29d717c8da" TYPE="ext4"
/dev/sdd1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="e51a267e-f2be-4202-a3ef-ee338968350d"
/dev/sdd2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="ad6e31ff-4002-22b2-79a5-f66ca815ee1a" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="4074e139-fba8-466f-bb63-e6e01827b5d2"
/dev/sdd4: UUID="a084a048-6978-450e-a326-bd82ab81785a" TYPE="ext4"
/dev/sdc1: UUID="fd2208cd-deed-8e53-fea7-3141da34f03c" TYPE="linux_raid_member" PARTLABEL="Linux swap" PARTUUID="07a98576-7fee-4944-9464-42b1b93edd9b"
/dev/sdc2: UUID="c1313c36-9e56-a51b-5092-13c3fee1bf24" UUID_SUB="abb832fe-2b2d-6faa-f4b7-b696224cb8b0" LABEL="1" TYPE="linux_raid_member" PARTLABEL="Microsoft basic data" PARTUUID="28b5df5a-b06e-4509-a024-57e13fd59787"
/dev/sdc4: UUID="cb05b2ed-2555-4ac0-a8c3-1fb38c952c10" TYPE="ext4"
/dev/md0: UUID="d18442c4-1816-46f2-9efa-6ceb4d642da6" TYPE="swap"
/dev/md1: UUID="0ddbf58d-693a-4731-819d-2736d4a373e7" TYPE="ext4"
/dev/mapper/docker-9:1-80347142-pool: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1" TYPE="ext4"
/dev/mapper/docker-9:1-80347142-b0cf4a948d6e1744d31feab8a471a604cdc87583ff9b5d7fc676eed5e359f292: UUID="bc20761f-907d-4361-a348-6440dd0b5fa1" TYPE="ext4"



I wasn’t having a go or anything :slight_smile: Sorry if I came across a bit harsh.

So basically 2/5ths of f#$% all and pretty much what was in the Release Notes only. Pretty disappointing :frowning:

That will only remove the symbolic link, wouldn’t you also need to remove /mnt/HD/HD_b2/Public as well ? I suspect that link in /shares will come back after a reboot of the unit.

An original alternative to /etc/init.d with some USB flash drive sauce.
It doesn’t touch the internal flash so it’s arguably better than the cron mods! :wink:


I looked at using this a while ago to try and get start up scripts to work and found that if I tried using it, there were some other key functions of the NAS that did not start right. I can’t remember the specifics but found it was not going to meet my needs as a result. So you might find if you go down the fun_plug route that some other key scripts and services are not started as a result.

I think you are doing great work on de-tangling the mess WD have left. Unfortunately life is getting in the way for me at the moment and not got the time I was hoping to have to contribute. :frowning:

Have you ever considered working on Github as an open source project?

did you by pass “chk_image”? Is there any side affects?

You are right about WD’s ownership.

I did the same once when I was experimenting, but reverted it to the original.


Docker used to be WDs tool of choice for installing custom apps onto these NAS units. Then they came up with the new Framework which they released and is now driven from the “Apps” tab in the Dashboard. I personally have docker used on my NAS and run SoftEther VPN in a docker container. Definitely great to have it on there although the docker version installed is getting a bit dated now.



Check out My Cloud Developer

Here’s an strace (installed with entware) of fan_control in debug mode:

It’s a loop with a countdown of 60 seconds and then prints temperature and fan info.
Might contain something of interest…

EDIT with more info:

fan_control 0 d

[fan_control.c:424] standby_flag=0
[fan_control.c:511] HD1 temperature 30
[fan_control.c:511] HD2 temperature 31
[fan_control.c:511] HD3 temperature 30
[fan_control.c:511] HD4 temperature 31
[fan_control.c:1939] current board temperature is 30
[fan_control.c:1940] current hdd temperature is 31
[fan_control.c:656] temperature=31
[fan_control.c:1438] current fan_rpm=510
[fan_control.c:776] uP cmd:up_send_ctl temperature 31 87
[fan_control.c:887] calculate temperature=31
[fan_control.c:890] WD daemon send alert
[fan_control.c:268] sleep duration is 60

Dig deeper to get any info on fan_rpm

strace fan_control -g 4
connect(6, {sa_family=AF_UNIX, sun_path="/var/run/wdtms.sock"}, 21) = 0
sendmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version=\"1.0\" encoding=\"ut"..., iov_len=202}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 202
recvmsg(6, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version=\"1.0\" encoding=\"ut"..., iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 253

This shows communication with the wdtms socket.

strace -e read=6 -e write=6 fan_control -g 4
    <?xml version="1.0" encoding="utf-8"?>.
    <?xml version="1.0" encoding="utf-8"?>.

Sure, have a look at the source code.

The script contains all you need.
When you have entware, just use

opkg install strace

A lot of info comes from running wdtms like this:

export LD_LIBRARY_PATH=/opt/wd/lib:/opt/wd/lib/boost
pkill wdtms
strace -f /opt/bin/wdtms -config=/etc/wd/BNFA-thermal.xml

I’m still going through, but you see commands passing by such as

i2cget -y 8 0x4c 0x10

This is polling the fractional byte of the temperature sensor… seems a bit useless to me but whatever.
More interesting is address 0x00 for the internal sensor and address 0x01 / 0x23 for the external sensors…

Digging deeper into the wdtms.

<?xml version="1.0" encoding="utf-8"?>.

And the response

<?xml version="1.0" encoding="utf-8"?>.

And using strace on wdhws gives a lot more info.

Fan control probably works over the serial bus at /dev/ttyS2, with params B9600 -opost -isig -icanon -echo.
Set the fan speed to 30 RPM as follows

{iov_base="FAN=1E\r", iov_len=7}

/opt/bin/opkg if you don’t update your path :slight_smile:

In the I copy some handy aliases to /etc/profile and I set the path as follows.

export PATH=/opt/bin:/opt/sbin:$PATH

I didn’t apply this to the interactive shell only yet… it’s on my TODO list :slight_smile:

I got a lot of info with this command:

strace -f -e read=7 -e write=7 -e read=3 -e write=3 -e write 15 -o wdhws_out /opt/wd/bin/wdhws -config=/etc/wd/sprite-wdhw.xml

Use the -f flag to catch all the forks, -o to write to a file and -e to capture all file access for the corresponding pointers.
I’ll now try to make a python replacement for these services that can be used on plain debian.

With strace, you can save the output to a file.
You’ll see that sockets are opened from wdtms to the wdhws.socket. This uses a file pointer (a number).
To get all data on that socket, capture the writes and the reads on that number.
Then I cleaned up the hex data to get the xml text.

A sample of the output when you listen to file pointer 3

first it reads a lot of library headers, until
open("/var/run/", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
4147  recvmsg(3,  <unfinished ...>                                                                                                                
4151  <... futex resumed> )             = 0                                                                                                       
4147  <... recvmsg resumed> {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="<?xml version=\"1.0\" encoding=\"ut"..., iov_len=2048}], msg_iovlen
 * 217 bytes in buffer 0                                                                                                                          
 | 00000  3c 3f 78 6d 6c 20 76 65  72 73 69 6f 6e 3d 22 31  <?xml version="1 |                                                                    
 | 00010  2e 30 22 20 65 6e 63 6f  64 69 6e 67 3d 22 75 74  .0" encoding="ut |                                                                    
 | 00020  66 2d 38 22 3f 3e 0a 3c  64 61 74 61 5f 6d 65 73  f-8"?>.<data_mes |                                                                    
 | 00030  73 61 67 65 3e 3c 69 6e  74 65 72 6e 61 6c 5f 69  sage><internal_i |                                                                    
 | 00040  6e 66 6f 3e 3c 76 65 72  73 69 6f 6e 5f 69 6e 74  nfo><version_int |                                                                    
 | 00050  3e 31 3c 2f 76 65 72 73  69 6f 6e 5f 69 6e 74 3e  >1</version_int> |                                                                    
 | 00060  3c 74 79 70 65 5f 73 74  72 69 6e 67 3e 48 57 47  <type_string>HWG |                                                                    
 | 00070  65 74 53 74 61 74 75 73  3c 2f 74 79 70 65 5f 73  etStatus</type_s |                                                                    
 | 00080  74 72 69 6e 67 3e 3c 2f  69 6e 74 65 72 6e 61 6c  tring></internal |                                                                    
 | 00090  5f 69 6e 66 6f 3e 3c 64  61 74 61 3e 3c 68 61 6e  _info><data><han |                                                                    
 | 000a0  64 6c 65 5f 73 74 72 69  6e 67 3e 30 78 62 31 38  dle_string>0xb18 |                                                                    
 | 000b0  38 32 30 3c 2f 68 61 6e  64 6c 65 5f 73 74 72 69  820</handle_stri |                                                                    
 | 000c0  6e 67 3e 3c 2f 64 61 74  61 3e 3c 2f 64 61 74 61  ng></data></data |                                                                    
 | 000d0  5f 6d 65 73 73 61 67 65  3e                       _message>        |                                                                    
4151  futex(0x7f8430002620, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>