[Please complete the below template with details of the problem reported on your Web-UI. Be as detailed as possible. Community members, including developers, shall try and help. Thanks for your time in reporting this issue! We recommend purchasing commercial support for expedited support directly from the developers.]
Brief description of the problem
Can’t configure Plex RockOn after stopping it. Actual error, since the forum won’t let me post it as the title: “Unknown client error doing a GET to /api/rockons/devices/152?page=1&format=json&page_size=9000&count=”
Detailed step by step instructions to reproduce the problem
@MainrtNr5 Thanks for the report.
I can initially chip in on the following:
Yes, this has been a long standing issue unfortunately in that the errors used for the title can be interpreted, via the create forum post mechanism, as forum commands in themselves. This has actually now been fixed, see the following issue:
This fix is due to be included in our now pending 4.0.6 release.
As you actual Rock-on issue. Could you let us know here the version of Rockstor you are running. And note that if it is an earlier CentOS based variant, where there was a bug in testing that prevented a successful transition to Stable you can double check via:
yum info rockstor
See the following forum thread for info no this known bug from quite a while ago:
This version number will help to diagnose the problem as there have been quite a few changes in the Rock-on system more of late.
Also, have you recently deleted any snapshots that were indicated as being on the Rock-ons root share (subvol): this is a potential cause of Rock-ons failure and another usability issue we have lined up for improvement:
But I don’t think this is what has happened in your case.
One possible work around, assuming you have followed the guidelines on using discreet shares for your required plex config/share etc, is to try uninstalling the Plex rock-on and re-installing. If you use all the same configurations (read shares/users) then it should pick-up from where it left. Also the mention of devices in the error message points to a more recent Rockstor version that introduced rock-on devices such as are associated with hardware encoding within rock-ons like Plex.
But before you try this, if you have the time, I’d await more comments here on the forum in case we can further diagnose what has happened here.
Hi @phillxnet, and thanks for the quick reply - as always.
I’m running 3.9.2.57 on 4.12.4-1.el7.elrepo.x86_64. I initially activated the test channel but then switched to the stable channel as I felt that was worth the £20 admission fee.
I did delete a bunch of Rock-on snapshots as I destroyed the pool to fix a bunch of things, like excluding my SSD drives, so that could very well be a reason.
After rebooting Rockstor the Plex Rock-on wasn’t installed so I re-installed it and now it seems to be working.
I’m still treating my Rockstor installation as a testbed so if I need to re-install or change anything it’s no big deal.
@MainrtNr5 Thanks for the update and glad your up and running again.
Yes, we really need to get on that Web-UI warning about rock-ons root snapshots actually being the docker images that back the rock-ons. But all in good time and I’m a little reluctant to add it to our Rockstor 4 milestone given it’s more an enhancement than a fix in the context of what we have there already.
On this note, and given our Rockstor 4 is well on it’s way to final release:
you might be interested in testing out our current/future state as it were:
Your Stable subscription is equally valid there, it’s just that we as-yet only have a 4.0.4 rpm placeholder in the Stable channel until we are happy we have feature parity with our now legacy CentOS base. But the outstanding issues to date are some Web-UI logging and AD/LDAP stuff that may not be of concern to you in your test-bed setup. Plus if you do find any issues we can act upon them, where as, due a combination of CentOS being an older base and some of our own intrenched technical dept (I’m working on that ) we are no longer releasing for the CentOS variant anyway.
Another advantage of the ‘Built on openSUSE’ Rockstor 4 variant is the years newer, and upstream supported, btrfs stack. This puts us on a far more solid and timely btrfs base. Something we failed to achieve maintenance-wise in our older CentOS variant.
Thanks again for the report and if you fancy jumping on the current/future 4 releases do let us know if you have any issues. And Thanks also for helping to support Rocksor’s development: much appreciated.
I actually looked at the 4.0 beta release but felt that I wasn’t good enough at Linux to make it happen. I’ll take another look and see if I can’t figure it out.
Thanks again for the prompt and informative reply.
@phillxnet - I managed to not only create an ISO of the 4.0 beta build but als install it on my testserver.
I can’t figure out how to apply my update subscription though as the Appliance ID seems to be different. I’ve searched the documentation and this forum but couldn’t find anything useful. Can you give me some pointers?
@MainrtNr5 Thanks for the update and well done on getting the ISO made and installed. Do keep us posted on how it goes. Whenever an ISO is built by this method the build process fetches and incorporates all upstream updates. So as time goes by you should begin to see new updates being offered on this install.
Re:
N.B. When re-installing on a different motherboard, or where the boards product_uuid is non unique, a different appliance id will result. This means the prior installs activation code will no longer work against the new appliance id. For this circumstance we have our in public beta test Appliance ID manager (appman). Please be patient as we work our the teething problems expected with newly release systems. Specific documentation will follow once we have established the less self explanatory elements.
We don’t however yet have the specific docs. But to date, in it’s current form, it looks to have been fairly easy to use from the feedback we’ve had so far. Again do let us know if you have any issues but be sure not to post your Appliance ID and activation code in the open forum.
Hope that helps and I’m glad you’ve got going on the 4 release. Once I’m done with my current pull request (end in sight) and reviewed @Flox’s pending pull request I’m hoping to prepare and release 4.0.6 release candidate 7.
Just to add my 2p to this, the Appman facility is really very useful and effective. I’ve used it a few times with various Rockstor builds and never had a problem.
I may or may not have encountered an issue with the beta (or Appman).
When I finally got access to the Appman application I found out I actually have the same appliance ID as the old installation but when I try to use the activation code I still get the error:
Activation code (xxxx) could not be authorized for your appliance (nnn). Verify the code and try again. If the problem persists, email support@rockstor.com with this message.
On a whim I decided to update the appliance ID in Appman, just to see if that would change anything, and after doing so I could activate my subscription.
The only difference in Appman is that the original appliance ID is all uppercase letters while the edited one is all lowercase, as I copied it straight from the Rockstor UI and pasted it in Appman.
Thanks for reporting this. I’m pretty sure we have had a prior report of this exact same case issue reported previously and I think it’s something to do with our ‘Built on openSUSE’ variant: which is quite strange. It’s on my list of things to check/resolve when I’m next on Appman duty.
Cheers, and apologies for the inconvenience on that front. Feel free to jump in on the forum is you suspect other forum members are affected by this.
Thanks again for the feedback and good luck with the new 4 series.
I stumbled on this error because I had the same problem on a new installation of Rockstor (4.5).
I solved it by adding a missing ‘fields = “all”’ to serializers.py for RockOnDeviceSerializer and also corrected an uppercase ALL to all somewhere. I’m not sure where the upper case problem was.
But now I can install Plex rock-on (and the Emby Rock-on).
Thank you for the clear report and well done on tracking that one down. I’m glad you got yourself up and running!
This does look like a bug indeed. the addition of fields = "__all__" to serializers.py was a recent modification required for a recent Django version update that @phillxnet accomplished recently:
It does seem indeed like this one slipped through the cracks but maybe @phillxnet left it without it there for a good reason. My bet is on the former but I would need to let @phillxnet chip in here. If this is indeed something that needs correcting, then we can create an issue for it.
I am unsure though as to why this one did come up in now legacy Rockstor v3 though, and why it didn’t come up earlier in v4, though, but that might be a bug that surfaces upon specific circumstances. You do mention it is a new installation so it seems like you did not have to do anything in particular to trigger this error, is that correct? Did you have the Plex or Emby Rock-on installed prior to the update to v4.5? Did you have any device defined there, by any chance?
Thanks again for bringing this to light and identifying a fix!
Yes, it is correct that the system was very ‘clean’.
Before reinstalling, I verified two backups because I wanted to start 100% percent clean. Then I wiped the beginning of the root disk with dd. I accepted the installers suggestion for partitioning and installed. I also reinitialized the two disk drives in my pool from rockstor and initialized the pool from scratch. Then I restored my files from backup to a new share. At this point I realized that I could not install the plex-rock-on.
I think I could have installed other Rock-ons, because not all Rock-ons triggered the error, but I didn’t install other Rock-ons as Plex was the most important, so I focused on that.
I’m afraid this one just fell through the cracks. We had to make hundreds of changes in that rather complex Django update. But I’ve not see the reported issue myself. And I’ve installed a number of Rock-ons, but not the ones mentioned in this report. It may be they are the reproducers. I.e. I last installed smokeping which went in and worked just dandy. This was with 4.5.0-0 and a source build of latest testing branch which is ear-marked for 4.5.1-0 once we get some rather gnarly technical dept situations sorted that @Flox and I are grappling with currently.
Yes, it is strange.
Our new install offers no partitioning options and does a disk wipe as a matter of course:
Or pre-build via the downloads page.
Could it be you are installing via the generic openSUSE route described here: Install on Vanilla openSUSE/SuSE SLES
It’s just your mention of accepting the partitioning options from the installer. When in fact there are none in our installer. We have a howto that indicates our installer steps: https://rockstor.com/docs/installation/installer-howto.html
I’m wondering if we have missed something on the by-hand install on top of a generic openSUSE instructions that is triggering something.
Thanks also from me for this report and for sharing your work around. Much appreciated.
I also hit that bug when updated to 4.5. and rockons didn’t work (…and I needed to manually first remove duplicate entry of the custom rockon in storageadmin).
Adding fields="__all__" to RockOnDeviceSerializer in serializers.py fixed it.
My apologies for not getting to this one sooner, especially given all the fix work has already been done by @frier. I’ve now finally taken a minute to open a proper issue on our GitHub repo so that we can create a PR and merge that fix in:
In previous talks with @phillxnet, we wanted to include that one as soon as possible so it may make it into the next testing release. @phillxnet has been hard at work to prepare this one so he’ll confirm/infirm.
Sorry again for the delay in getting that on the way, but I believe we’re almost there.
) we are no longer releasing for the CentOS variant anyway.