@b8two Welcome to the Rockstor community and thanks for the feedback.
Re:
This use to be the case and is again in our openSUSE channels (early releases as yet) but we stopped releasing rpms in the testing channel for our soon to be legacy CentOS base around Nov 2017:
which is equivalent to the last testing channel release on CentOS of 3.9.1-16.
The original post in our Stable Channel updates thread explains this:
So in the interim there have been many releases and improvements both on our side and in upstream.
However we have now re-activated the testing channel but only for our new ‘Built on openSUSE’ base, see the following forum thread for this:
Our Update Channels doc section alludes to this plan but as this is currently pretty early days in our transition, at least on the public release side, I haven’t yet updated the docs. But soon hopefully.
And we are currently releasing in unison to both channels but as follows:
- Stable Channel: Our based on CentOS offering.
- Testing Chennel: Our ‘Built on openSUSE’ offering.
Where they are build from the exact same source code although due to ditro differences, which we are currently working on fixing, there are often different ‘paths’ within that same code.
The caveat is that currently we have no publicly released installer for our ‘Built on openSUSE’ variant so one has to start with a Leap15.1 or Leap15.2 beta install and make the minor modifications listed in the thread above.
I’m actually currently working on cleaning up/improving the automation element of creating Leap15.1, Leap15.2beta, and Tumbleweed based installers. And we have current testing channel rpms available now for all of these. The installer build system I’m working on currently pre-installs these testing channel rpms but once we have feature parity with our CentOS based offering we will reverting to installing a Stable channel rpm into these installers. As per our prior release strategy for our installers.
Yes the erros in the log are what inform the “Not Supported” condition with the Web-UI. We essentially try to enable smart and if there is an error we say it’s not supported. Sometimes there is a work around via custom smart options detailed in our S.M.A.R.T doc entry, specifically the “Disk Custom S.M.A.R.T Options” subsection which uses this common smart error log as an example. Many USB devices just dont’ support smart but some do with a custom switch.
Some of the dive is swap and boot, the rest btrfs; hence not all available.
No, but pull requests are welcome. But we have had near zero requests for this. Rockstor is not aiming to be all things to all folks, but to do the most used things well: and there is much for us to still do in this regard of course 
.
No, and this is unlikely to be added. We are specifically btrfs and the additional complexities in supporting this are better addressed by systems that aim to be everything and the kitchen sink. But you could create a new pool with an external btrfs whole disk and share that out via it’s subvolumes.
Yes this is an excellent idea. Thanks. It has been considered but of course we always seem to have more pressing stuff on. Especially during our multi year transition to the ‘Built on openSUSE’ re-launch. Would you care to create a GitHub issue for this. As it will require quite a few changes in the core code it would best be placed in the rockstor-core repo:
there will also have to be additional maintenance / voting / feedback to maintain these and changes in the back-end support infrastructure that uploads these and some kind of transition over to this system that doesn’t break every existing install so it’s definitely no trivial but there is merit in the idea and we can gather ideas around it’s implementation under the suggested issue.
Yes agreed. But as usual that is easier said than done. We do have existing issue open of such an enhancement here:
But we have some improvements that need to be in place within the Rock-on definition first before we can viably implement this kind of one click install and the like. But it’s definitely a goal.
That strange as I tested that one myself recently prior to merging it. I know that our now over 2 year old CentOS testing release still uses the older docker where as Stable release and testing channel for openSUSE have long since moved to docker-ce. See the following proof of function prior to merge:
Take a look there and see if you find any clues as to why it’s not working for yourself.
You are more than welcome to contribute some and put in reproducible methods for your issues on all of these Rock-on issues in our Rock-ons page. Some docker images may just have fallen into disrepair and we are happy to delete them if that is the case. And have recently removed some for similar reasons or through being replaced by better options. Please keep in mind, as you state, that we depend upon the community to help with this project of ours. And your points failure each need to have exact reproducers detailed in individual GitHub issues located in the correct repository so that other’s might pick them off if they fancy stepping up to the task.
Again this is one I proved working myself and @Flox also tested it as working, although we likely used more recent versions of Rockstor as that makes more sense moving forward. And we usually pove the function of each rock-on in both our CentOS and Leap variants. Though both use docker-ce.
So this may be further evidence of an issue with your particular setup. I’d suggest using a more recent Rockstor version for your trials. Especially since have have had so many issue that have not otherwise been reported by others.
Yes, another nice idea. This could be another button, against each rock-on, that is only shown when an advance option is ticked within the rock-on web-ui. Please consider making this an issue in the core repo as that is where the code would have to be:
And inviting some discussion on how best to implement this both in the back-end as well as within the Web-UI here on the forum, in a fresh post, would be good.
I’d like to invite you to try a more recent rockstor version as many issue you have reported don’t have confrontational reports. Also note that your follow up post:
Could account for any number of issues. Linux systems with no root space are typically a house of cards as they need working root to function.
Thanks for putting so much effort into this report, I’m not convinced that your root full issue didn’t spill over to many of your other issues however and would be interested to see if you can reproduce especially your issues with the Rock-ons I mentioned with a more recent version of Rockstor. In this light I will contact you via PM about this. Also note that regular USB key drives just don’t work with rockstor. We are not a cut down linux my any means so absolutely require fast USB key not regular ones, although ssd or hdd is far preferred. See our Minimum system requirements on this.
- 8GB drive for Rockstor; if USB key use only fast variants (16GB+ SSD recommended).
And this recommendation is likely to double for our imminent ‘Built on openSUSE’ variant.
So thanks again for the feedback and I look forward to potential follow-ups regarding more recent versions of our offerings. Either via the Stable Chanel or our current ‘Built on openSUSE’ testing channel. I’ll contact you via PM for options there.
Hope that helps, even if it is only to clarify our current development.