wdpksrc
wdpksrc copied to clipboard
OS5 packages
I've got the new toolchain for OS5. Only minor changes for 3rd party packages. I'll probably do an overhaul over the project soon.
Stay tuned.
Docker 19.03.8 for OS5 docker-19.03.8-OS5.zip
Works on PR4100. Looking for confirmation on other platforms. Based on OS5 branch: https://github.com/WDCommunity/wdpksrc/tree/OS5
clarification on what FW is OS5?
Docker 19.03.8 for OS5 docker-19.03.8-OS5.zip
Works on PR4100. Looking for confirmation on other platforms. Based on OS5 branch: https://github.com/WDCommunity/wdpksrc/tree/OS5
Any chance adding WDMyCloudMirrorGen2_docker_19.03.8.bin for OS5?
clarification on what FW is OS5?
5.02.134
root@4762f36cacea:/wdpksrc# ./mksapkg-OS5
ERROR: model_name not specify
Usage: mksapkg-OS5 -E -s -m [model_name]
Supported model_name:
WDMyCloud
WDMyCloudEX4100
WDMyCloudDL4100
WDMyCloudEX2100
WDMyCloudDL2100
WDMyCloudMirror
MyCloudEX2Ultra
MyCloudPR4100
MyCloudPR2100
WDCloud
root@4762f36cacea:/wdpksrc# ./mksapkg-OS3
ERROR: model_name not specify
Usage: mksapkg -E -s -m [model_name]
Supported model_name:
WDMyCloudEX4
WDMyCloudEX2
WDMyCloudMirror
WDMyCloud
WDMyCloudEX4100
WDMyCloudDL4100
WDMyCloudEX2100
WDMyCloudDL2100
WDMyCloudMirrorGen2
MyCloudEX2Ultra
MyCloudPR4100
MyCloudPR2100
Seems like it is no longer supported. Which is odd as you are on OS5. I'll ask for clarification.
You may try the other packages, I'm fairly sure one of the other packages should work fine.
I have tried all from your zip file and all failed
https://community.wd.com/t/my-cloud-os-5-firmware-for-my-cloud-mirror/256504
The OS is still Indexing , not sure if this might influence the installation.
hello Stefaan , do you see any major roadblocks on your end to extend the DOCKER packages to WD My Cloud Gen 2?
@Vendo232 try the Mirror package in this new zip. I think they just renamed the MirrorV2 to simply Mirror. The old V1 did not support Docker so it was not part of the build script.
Docker 19.03.8 for OS5 docker-19.03.8-OS5.zip
Works on PR4100. Looking for confirmation on other platforms. Based on OS5 branch: https://github.com/WDCommunity/wdpksrc/tree/OS5
Works on PR2100 OS5
So are these OS5 packages still valid for the PR4100/PR2100 NAS units? Seeing seriously mixed messages between here and the WD forum?
So are these OS5 packages still valid for the PR4100/PR2100 NAS units? Seeing seriously mixed messages between here and the WD forum?
The zip on this thread works just fine for me in PR2100.
@ricardoespinobon thanks! I just updated to OS5 and installed the Docker app without issue! (PR4100)
Verified docker for PR2100 OS5 -- Happy to test entware for OS5... though i was able to get Transmission & Flexget configured in a container (wiserain/docker-transmission) so that not be necessary
Entware failing on upload into OS5.
Not works on EX2Ultra, it fails on docker run
with this error:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"mqueue\\\" to rootfs \\\"/mnt/HD/HD_a2/Nas_Prog/_docker/vfs/dir/c13d78eea5a514e034fcaa369fdd8fb2d9d0e2c647437e1e5ce100dd186e5780\\\" at \\\"/dev/mqueue\\\" caused \\\"no such device\\\"\"": unknown.
@Perlets9 yeah this is the same error as what I was getting on the EX4100. The kernel WD have supplied does not have mqueue support compiled in.
JediNite
Under OS5, I am suddenly unable to connect from one Docker container to another. That is, if I run
docker run --name $NAME -p 9001:9000 --restart=always -d -v /mnt/HD/HD_a2/minio:/data -e "MINIO_ACCESS_KEY=$ACCESS_KEY" -e "MINIO_SECRET_KEY=$SECRET_KEY" minio/minio server /data
and try to access that container from an nginx container (or whatever), and run:
curl -v 10.0.1.232:9001
* Expire in 0 ms for 6 (transfer 0x5588b8cfff50)
* Trying 10.0.1.232...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5588b8cfff50)
* Connected to 10.0.1.232 (10.0.1.232) port 9001 (#0)
> GET / HTTP/1.1
> Host: 10.0.1.232:9001
> User-Agent: curl/7.64.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host 10.0.1.232 left intact
curl: (52) Empty reply from server
Curiously, I can still access minio remotely (the same curl command from MyCloud outside of Docker or from another machine works fine). It's only from one container to another that's broken.
This worked prior to upgrading to OS 5. Now I need to figure out an alternative somehow.
Update: I switched nginx to host
networking, and am able to connect to the other container. Something isn't working with bridge
networking in OS5.
Not works on EX2Ultra, it fails on
docker run
with this error:
docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "process_linux.go:449: container init caused \"rootfs_linux.go:58: mounting \\\"mqueue\\\" to rootfs \\\"/mnt/HD/HD_a2/Nas_Prog/_docker/vfs/dir/c13d78eea5a514e034fcaa369fdd8fb2d9d0e2c647437e1e5ce100dd186e5780\\\" at \\\"/dev/mqueue\\\" caused \\\"no such device\\\"\"": unknown.
Exactly the same here.
Are we SOL then without mqueue support in kernel? Thanks Brent
@koehn.
Update: I switched nginx to host networking, and am able to connect to the other container. Something isn't working with bridge networking in OS5.
Did you try creating a custom bridge network or are you using the default bridge network that is installed with docker ?
https://docs.docker.com/network/bridge/ may help ?
Cheers,
JediNite
@Vendo232 try the Mirror package in this new zip. I think they just renamed the MirrorV2 to simply Mirror. The old V1 did not support Docker so it was not part of the build script.
Stefan I was able to install Docker on Mirror V2 but the :9000 Portainer is not opening, any idea what could be wrong?
Did you try creating a custom bridge network or are you using the default bridge network that is installed with docker ?
I was just using the default bridge network, trying to communicate between two containers launched thusly:
Minio:
docker run --name $NAME -p 9111:9000 --restart=always -d -v /mnt/HD/HD_a2/minio:/data -e "MINIO_ACCESS_KEY=$ACCESS_KEY" -e "MINIO_SECRET_KEY=$SECRET_KEY" minio/minio server /data
Nginx:
docker run --restart=always --name=$NAME -d -p 9443:443 -p 9080:80 -v $PWD/nginx.conf:/etc/nginx/nginx.conf -v $PWD/conf.d:/etc/nginx/conf.d nginx
Nothing fancy, and those same scripts worked prior to the OS 5 upgrade. Now the nginx container cannot communicate with the port that the minio container is exposing (10.0.1.123:9111
, where the WD's IP is 10.0.1.123
) unless nginx is run on the "host" network. It's not a show-stopper for me, and you should be able to reproduce it with those scripts (or a variation), but I thought you'd want to know.
Thanks for all your hard work on this project! Much appreciated!
@koehn,
Double check within the "daemon.sh" script that it has this line :
${DOCKERD} --ip-masq=true >> /var/lib/docker/docker.log 2>&1 &
If this is missing, it may also be the cause. For some reason I found on the EX4100 (prior to OS5), that IP masquerading was not being enabled by default unless the daemon was started explicitly with the option. I know @stefaang has added this into the branch code though, so you should have it there if using the latest. If you really do want to try and use bridge networking, would recommend creating a custom bridge network and see if it makes a difference.
Cheers,
JediNite
I'm sorry; where do I find daemon.sh
? I've looked in a bunch of locations but it hasn't turned up.
I'm sorry; where do I find daemon.sh? I've looked in a bunch of locations but it hasn't turned up.
@koehn ,
Try looking in "/mnt/HD/HD_a2/Nas_Prog/docker"
Cheers,
JediNite
Thanks! I found the file, and it has the line you indicated, exactly as you mentioned it above. A quick ps
shows that it is running with --ip-masq=true
.
I had the same issue trying to get two containers to communicate with each other using the default bridge network. I ended up creating a new bridge network and assigned the containers to that, and the issue appeared to be resolved. I'm on a PR4100
I had the same issue trying to get two containers to communicate with each other using the default bridge network. I ended up creating a new bridge network and assigned the containers to that, and the issue appeared to be resolved. I'm on a PR4100
@maxnl Can you detail how to do that in portainer? or did you have to sshd into it?
@JediNite, are there any workarounds for the issue @Perlets9 and @brentgl encountered since I have the same problem with mqueues. I would really appreciate a working docker since Transmission app is missing and the sql database is limited to localhost access on My Cloud OS 5.
Best regards, Marko
@JediNite, are there any workarounds for the issue @Perlets9 and @brentgl encountered since I have the same problem with mqueues.
I would really appreciate a working docker since Transmission app is missing and the sql database is limited to localhost access on My Cloud OS 5.
Best regards,
Marko
@vacovnik,
There is nothing that can be done as a workaround as the kernel needs to be rebuilt with mqueue support. I saw recently on the WD forums that a large number of people have raised concerns about docker being removed from the OS5 release so at least it is on their radar to fix. The post appeared to indicate WD are looking to fix in a future release.
Cheers
JediNite