I just found out the “hard” way, that the new Plex version that’s shown inside the Media Server page is apparently not available on the download page. This has the consequence that during a restart of the Rock-on the linuxserver.io docker version of Plex attempts to upgrade, but cannot find it, aborts the upgrade, and then seemingly makes the rock-on non-functional.
On my box it means that Plex shows as started (both on WebUI as well as in CentOS) and running, but when checking the docker logs for it, it shows that the installation is aborted …
I suggest to wait a day and possibly check out the forum entry over at Plex whether that has been fixed).
https://forums.plex.tv/t/pms-1-15-0-659-download-offline/372703
Addition. Apparently, when/until the update fails inside the container it takes a while. the “old” version came back online about 30 minutes later … I guess, wait and see is sometimes the best remedy.
Looks like this only affects users with a Plex Pass. As the most recent free version is avail.
Well, this morning trying the RockOn stop/start to update the Plex version still didn’t work.
It appears the API/had changed at Plex. I finally figured out on github that linuxserver.io adjusted its images 4 days ago (after this issue was reported) to fix the download.
On my side, I assumed, just restarting the Plex RockOn would ensure that the latest version of the Plex AND the container would be pulled … that does not seem to be the case, or at least was not my experience (and I only noticed that for this particular problem).
In order to address the Plex API change for updates, I essentially had to stop/uninstall/remove the docker image from my server, and then reinstall the Plex Rock-On (using the same settings as before, so I did not have to rebuild my library/plugins, etc.).
Interestingly, the first time around, it did not work correctly. It continued to use the old image - checking using console, the “old” image still lingered (I thought the Rock-On uninstallation would remove it automatically from the system).
My remedy (right/wrong/indifferent) was to run manual docker pull of the image, shut down the Plex RockOn, select uninstall and also manually remove that container image (which I had noted down earlier).
Now, upon reinstalling the RockOn, it looks like it’s using the “pulled” plex container, which is now updated to its latest version, and the Plex update seemed to have worked correctly to version: 1.15.0.659
@phillxnet - maybe you can clarify one more time for dummies like me.
When restarting a RockOn:
Will only the app within the container be updated, or if there is a newer version of the container itself as well (like a docker pull)? I know @Haioken and @Flox haved weighed in on that in some past posts …
Hi there,
First of all, thanks a lot for letting everybody know about that problem with Plex image.
I’ll answer your question regarding how Rockstor handles the docker images for rock-ons.
Briefly, we simply pull images at the rock-on install, not restart.
In more details, the code in question is below:
As you can see, @suman added an explicit docker pull image during the install process, which means that we pull a new image before running the container(s) of a given rock-on. It still follows docker’s logic, however, so if no newer image is found on docker hub when compared to what exists locally, nothing will be pulled and docker will simply use the local image.
Now, when you write the following:
… it seems something went wrong somewhere as Rockstor’s logic should have worked. Maybe the updated image was not published on docker hub yet and you happen to have tested it right before it got published, but that seems quite the coincidence if you tried the “manual” way right after that.
Note that we do have some improvements in line for these Rock-ons/Docker-related operations to facilitate “forcing” them when needed. See this discussion, for instance, but you’ll find more throughout the forum and Github repos. The Rock-ons system is in active development right now so things are moving. That also means that if you have any feedback, ideas, suggestions on how we can improve this, please don’t hesitate to share!
Hope this helps, and thanks again for your original post!
1 Like
@Flox
thanks for the detailed explanation, that helps. I, too, think that it would have been too great of a coincidence that they republished right before/after my testing. May be there wasn’t an image version increase or something like that.
Good to see that there is additional active development in the RockOn space.
One question remaining is that when uninstalling a RockOn, should it not also remove the associated docker image with it? What I saw was, that after uninstalling the RockOn, the actual docker image still persisted (though not running obviously).
And, maybe that’s going down the rabbit hole, so feel free to defer an answer to the docker forums: when the pull occurs and a new image is found, the resulting docker image on Rockstor would show the new “create date” (of when the image was actually created and put into the docker repo), correct? If so, on the plex image I couldn’t see that, because it would still show the create date from 2 years ago (when using docker images or the docker inspect), though there have been some updates to it over time) … although I should differentiate between the docker image and the plex version (of which the image always pulls the latest, aside from this time around due to the API changes).
Thanks again.
You are correct, the image remains after rock-on uninstall. As you could see in the discussion, however, this will most likely be re-visited soon. Whether this will be entirely automatic, manual, or in-between (akin to a schedule task, for instance) is still subject to discussion so feel free to provide ideas / feedback.
I’m not 100% familiar with the details on this one, but yes, the “CREATED” date corresponds to the build on the docker hub. For instance, I just pull a new linuxserver/plex image and I see:
[root@rockdev ~]# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
linuxserver/plex latest 1479bbd6ccab 5 hours ago 366 MB
If you look at the image’s history, you can see that changes were made 5 hours ago, and then 4 days ago before that:
[root@rockdev ~]# docker history linuxserver/plex
IMAGE CREATED CREATED BY SIZE COMMENT
1479bbd6ccab 5 hours ago /bin/sh -c #(nop) VOLUME [/config /transc... 0 B
<missing> 5 hours ago /bin/sh -c #(nop) EXPOSE 1900/udp 32400 3... 0 B
<missing> 5 hours ago /bin/sh -c #(nop) COPY dir:1138c56cbc88668... 6.78 kB
<missing> 5 hours ago |3 BUILD_DATE=2019-02-13T11:56:47-05:00 PL... 240 MB
<missing> 5 hours ago /bin/sh -c #(nop) ENV DEBIAN_FRONTEND=non... 0 B
<missing> 5 hours ago /bin/sh -c #(nop) ENV NVIDIA_DRIVER_CAPAB... 0 B
<missing> 5 hours ago /bin/sh -c #(nop) LABEL maintainer=sparkl... 0 B
<missing> 5 hours ago /bin/sh -c #(nop) LABEL build_version=Lin... 0 B
<missing> 5 hours ago /bin/sh -c #(nop) ARG PLEX_RELEASE 0 B
<missing> 5 hours ago /bin/sh -c #(nop) ARG VERSION 0 B
<missing> 5 hours ago /bin/sh -c #(nop) ARG BUILD_DATE 0 B
<missing> 4 days ago /bin/sh -c #(nop) ENTRYPOINT ["/init"] 0 B
<missing> 4 days ago /bin/sh -c #(nop) COPY dir:22123dbed7dc193... 660 B
<missing> 4 days ago |3 DEBIAN_FRONTEND=noninteractive OVERLAY_... 37.6 MB
<missing> 4 days ago /bin/sh -c #(nop) COPY file:1274153a0a2f7d... 1.82 kB
<missing> 4 days ago /bin/sh -c #(nop) ENV HOME=/root LANGUAGE... 0 B
<missing> 4 days ago /bin/sh -c #(nop) ARG DEBIAN_FRONTEND=non... 0 B
<missing> 4 days ago /bin/sh -c #(nop) ARG OVERLAY_ARCH=amd64 0 B
<missing> 4 days ago /bin/sh -c #(nop) ARG OVERLAY_VERSION=v1.... 0 B
<missing> 4 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
<missing> 4 days ago /bin/sh -c mkdir -p /run/systemd && echo '... 7 B
<missing> 4 days ago /bin/sh -c sed -i 's/^#\s*\(deb.*universe\... 2.76 kB
<missing> 4 days ago /bin/sh -c rm -rf /var/lib/apt/lists/* 0 B
<missing> 4 days ago /bin/sh -c set -xe && echo '#!/bin/sh' >... 745 B
<missing> 4 days ago /bin/sh -c #(nop) ADD file:e44b0f2febae798... 88.2 MB
Note that if you haven’t uninstalled and re-installed the Plex rock-on in 2 years, Rockstor shouldn’t have even tried to pull a new image so I would expect it to show as being 2 year-old. Now that I think of it, that’s a drawback of the Linuxserver.io’s approach of updating the container’s project at restart rather than the traditional docker way (pull a new image).
@Flox, ah yes, that all makes sense. I had reinstalled plex once or twice during the last two year, but the image still appeared to be the same (considering create date, and using the inspect command). Thanks for spending so much time on this.
From a feature perspective, I think, especially since linuxserver offers quite a few dockerized setups, the ability to “remove” image upon uninstall (as a checkbox option after selecting the uninstall button) might be a good idea. That way, one could possibly clear up some “weird” scenarios that had been posted on the forums over time, where an install from “nothing” could help and not requiring to use the shell to do so.
Additionally, I think (without trying to restart the discussion about usefulness of running your life with Rock-Ons on a system that is designed to primarily be a NAS 
) it would be good to have a “packaging” facility that allows to build the Rock-On JSON files … either based on the docker build instructions that are posted or something similar, but that might be a very tall order (as I don’t know how much variety really exists in the docker world).
Thanks again for the help!
To summarize: to resolve my issue that Plex would not update (even after using the uninstall/install procedure in the RockOn GUI, I essentially had to:
- uninstall the Plex RockOn (keeping the config and media shares and record the settings for ports, etc.)
- At the shell level, find the docker container for plex. Command: docker images
-
remove that container (I didn’t have to use the --force option as the uninstall took care of stopping the container and plex did not have any dependencies on other running images).
Command: docker image rm -
Use the RockOn UI to reinstall Plex. And voila, it all came back together and worked (and the latest Plex version was there, too)
1 Like
I do like the idea, yes, and it would provide consistency with how we offer a “force” option when deleting shares, for instance. Thanks a lot!
Agreed… We actually already have an issue opened for such a feature and @phillxnet brought interesting insight:
Thanks again!