BETA "Built on openSUSE" Testing Channel Changelog

I am delighted, and somewhat relieved, to finally announce after more than 2 years of transition from our CentOS base, our first BETA release within our “Built on openSUSE” only testing channel.

We are, as yet, not quite at feature parity with our prior CentOS variant (Stable Channel) but getting very close. The intention is to finally offer a Stable Channel rpm for our “Built on openSUSE” rpms once we have this final beta testing phase completed successfully. As always there are wrinkles and one is that our current target disto Leap15.2 is still in beta; but this is our attempt to skate to where the puck is going. There after the testing channel for the Rockstor4 series will settle into the some what non trivial task of dealing with our other outstanding ‘out-of-date’ elements, Python and Django versions mainly, so it will return to being very much more developers only.

This forum thread picks up in part from the following thread but for a wider audience:

But as we still as yet only have private beta testing releases of our new ‘Built on openSUSE’ installer there are sill a few hoops to jump through. Currently they are all still as documented in the above early-adopters post.

And given we are now on the ‘last leg’ of this rather long and drawn out journey I’m also going to pickup from the following thread/post:

Given we are now deviating away from the CentOS base and can finally concentrate fully on our ‘Built on openSUSE’ endeavour; which is the future of the to-be Rockstor4 variant, I’ll begin this beta changelog thread.

Thanks to all those helping to support this endeavour, either via testing/code/doc contributions or via a Stable Channel subscription.



Released 20th May 2020

Reboot required

So this one is just a little tricky. As per this threads into, we have finally tackled one of the all time outstanding feature disparities between our current CentOS based Stable channel and our ongoing ‘same source’ ‘Built on openSUSE’ variant. This ongoing dual distro target approach has in many ways slowed our progress, but we absolutely depend on our Stable Channel subscribers to ‘keep the light on’ so we have maintained compatibility with both distro bases with a priority on our Stable Channel release. But as from this release, our source code is only intended to run on an openSUSE server install with the very specific configurations discussed in the “early-adopters” link. And as such we can finally make the fairly major changes required to support user share functionality on a boot-to-snap, aka rollback capable, system poll that is default on all openSUSE based installs when the system disk is greater than around 17.5 GB. Previously, and share created on the system pool of our ‘Built on openSUSE’ variant, assuming no other issues were in play, would seem to have been created as normal but disappear from the Web-UI upon browser refresh. There were in fact created as btrfs subvols but, as it turns out, in the wrong place. Primarily because were were just plain ‘doing it wrong’ on these boot-to-snapshot root rollback capable systems. Which leads me to a potential wrinkle here. If you are updating from a pre beta ‘Built on openSUSE’ version and you attempted to create a share on the system pool then you will have a little tidying up to do.

There is no migration of these prior user created ROOT pool shares as they were never functional within the Web-UI (as per the early adopter thread), unless you did not have a boot-to-snap config in play, and are only now actually persistent given we now no longer place them in the boot-to-snap root subvol, but more correctly within the @/ subvol akin to the also surfaced with the Web-UI “home”. Please note the following forum post if you want to clean up ‘by hand’ any previously inadvertently created shares in the ROOT pool:

But in all cases, with 3.9.2-58 onwards, post reboot, you should expect to see the following mount details, subvol wise, for the ROOT pool.

If you see mention of “snapshot” within that subvol for the ROOT pool then stuff is not going to work as intended. Look to the logs for clues and it could be that prior use of the ROOT pool, when we ‘did it wrong’ for the openSUSE may be the cause. And given we are now starting a fresh it may just be worth doing a fresh install anyway. Depending on your own btrfs / linux capabilities. Remember that this is our very first beta in the ‘Built on openSUSE’ endeavour and the testing channel is just that. A testing channel for our Stable release developments. We are trying to achieve production capable Stable Channel releases ultimately, via the well trodden but rarely sustainable open source development model. So if you do encounter any strangeness re ROOT system pool shares that is not covered in this announcement and it’s linked threads, then try a fresh start (re-install) beginning with this release or any that superseded it before reporting your issues. That way we have a known datum from which to work.

So, many words and may fixes to announce:

First off I would like to welcome first time contributor @kupan787 who has effectively updated our scrub reporting to include an ETA and observed rate by interpreting some upstream btrfs improvements, and when they are not found (i.e in when btrfs-progs is not quite new enought) the code adapts accordingly. Nice. This is a long planned Rockstor feature that is now finally here. So thanks again to @kupan787 for stepping up to this task. Aided by the venerable @Flox via a super helpfull code review or two.

The rest are as detailed in the linked issue and as can be seen @Flox, our intrepid forum moderator and code/doc/rock-on/forum contributor has been at it again. Dealing with three independant issues getting us ever close to our next Stable release. Thanks @Flox. And as a matter of interest my initial main pull request for this release (the ROOT shares thing) was also reviewed by @Flox, and lets just say I’m glad it was. Code reviewing is a major part of helping to develop better behaved software, so if anyone feels they can contribute in that fashion then do please step up whenever you see a pull request go in. On occasions a specific reviewer is requested but often times anyone with the capability to review the proposed changes and is able to build the code from source on the indicated distro is more than welcome to do so.

I would also like to thank recent forum member @freaktechnik, for stepping up to some early testing in our pre-beta testing channel related to this release. The SFTP issue referenced was submitted by them and they have now duely confirmed it’s fix.

So bit by bit and thanks to all those continuing to chip in here.

Finally, as always, a special thanks to all Stable channel subscribers without whom this whole endeavour would be unsustainable. The Rockstor 4 ‘Built on openSUSE’ days are nearing.

1 Like


Released 7th June 2020

Signing Key update required

I am delighted to be releasing our second ‘Built on openSUSE’ beta rpm version. The main upset (we are in the testing channel here) as per the header, is that we have a new signing key. This one is my fault as I wanted to get this chicken/egg problem over and done with for the next keys duration (5 years) before we began our new Stable channel releases. All that is required is to re-run the prior rpm key import command introduced in our ‘… early adopters…’ post. Namely:

rpm --import

Then all should be set in this regard for the next 5 years (hopefully :slight_smile: ).

As usual all rpms were build natively on their target distro platforms but of note in this release is that our base openSUSE Leap15.2 distro has turned from it’s prior beta status to Release Candidate (RC), and Tumbleweed has been build, from the ground up, with gcc10.1. All build systems were fully updated prior to their respective build tasks so if you do have any issue make sure your systems are fully updated.

To the change points. Again, as usual, I would like to thank @Flox the intrepid, who in responsible for 2 of the 3 changes in this changelog:

I have already covered the new signing key, ready for the ‘Built on openSUSE’ Stable Channel re-launch, and as is our current focus both of @Flox’s linked issues also concern our pending re-launch. There has also been a few changes in our backend build system as we prepare for the pending Rockstor4 Stable Channel re-lanuch (Built on openSUSE only). @Flox has also been helping greatly with our closed beta installer release. We have a few odds and ends to sort on that front that has begun to slow our normal release cadance but once sorted we should be back to normal but with a shiny new installer.

Thanks also to all our testers. We do have a little way to go and I’m slowly working though my own backlog but we are getting there. If you have submitted a bug of late please be patient as this has ended up being quite the journey. Also note that we are now no longer able to build on CentOS. But as we are now almost at feature parity we should soon be able to recommend folks use our new installer anyway. A call will be put out here for beta installer testers shortly. But given our target re-launch distro platform is Leap 15.2 we have a few short weeks before it’s final release anyway. So do please keep the bug reports rolling and we can see what we can make of all this.

So in that light I would like, as usual, to thank our Stable Channel subscribers without whom this whole endeavour would be unsustainable. The Rockstor 4 ‘Built on openSUSE’ days are nearing.



Released 29th June 2020

Additional rpm dependencies

In this release I would like to welcome another new contributor, mcbridematt (on GitHub) with what was our 800th pull request merge in the main git repo. In this case an exciting move toward AArch64 compatibility; in which mcbridematt has non trivial expertise. Nice. Encouraged by this contribution and mcbridematt multi year interest in Rockstor behind the scenes, I’ve set to on popping in a couple of trivial arm64 compatibility improvements myself.

To the summary of changes:

And I would also like to thank forum members and intrepid testers @Azzazel, @Zonk, and @kupan787 for their reporting, and patience, with regard to the remaining change detailed above, that of Rockstor’s inability to allow for the removal of ‘detached’ disk in some (read a lot) of circumstances. This was predominantly cosmetic but was also a functional hole in our more recently re-vamped disk/pool management systems. And thanks as usual to our talented forum moderator and across the board contributor @Flox for also reviewing this long awaited fix. Please note that the Changelog entry within the rpm only includes the first “Fixes” link for this last detailed issue as we have an outstanding bug where our Web-UI can only link successfully to a single issue.

So thanks again to all our testers. We are getting there, bit by bit, but only with the continued help and experimentation of those happy to chip in where they can with their time and expertise. Your contributions are of course much appreciated. Soon we should be able to move an ‘earmarked’ rpm from testing to our ‘Built on openSUSE’ Stable channel repos. So again, please keep all bug reports rolling as we do, soon, need to move onto our ‘other’ technical debts of moving to Python 3 et al (read Tumblweed again). Which is the intended next focus for the testing channel once we have a workable ‘Built on openSUSE’ stable release rpm out and about.

Oh, and did I mention we have AArm64 rpms now; natively build, as per all our rpms, on their target distro and architecture. :sunglasses:

Finally; thanks to our Stable Channel subscribers, without whom this whole endeavour would be unsustainable. The Rockstor 4 ‘Built on openSUSE’ re-release is just around the corner, just in time for Leap 15.2’s official release.



Released 21st July 2020

Stable Release Candidate

So we finally have our very first Rockstor 4 release. As per the title, this is a proposed release candidate for finally beginning our ‘Built on openSUSE’ Stable channel re-launch. Our last stable channel update was 3.9.2-57 which was almost 3 month ago. And as some of you may have noticed we have, a little optimistically, aimed more recently at a release frequency of 1-2 week or months depending on testing or stable channel respectively. And given our Stable subscribers are critical to the continued existence of ‘The Rockstor project’ as it currently stands, I would very much like to quickly re-establish this critical element of Rockstor’s sustainability. Our CentOS releases became unworkable just a littler earlier than I had hoped, but the silver lining was that we were able to focus completely on rounding out our last 2 years of work in establishing our new distro base and that is what this release represents.

Please test, and report, as the sooner we establish what is hopefully a lack of show stoppers, the sooner we can finalise our preparations for beginning the hopefully far quicker next major task: project wide updates across the board of technologies. Aside, of course, from finally releasing our next installer which is planned for when we have the ‘Built on openSUSE’ stable channel in play. More on this soon.

The technical debt task is much needed and will inevitably break stuff but that is why we have the testing channel: and all our prior stable releases have been developed similarly from the testing channel. But do keep in mind that the degree of change required (Python 2 to 3, multiple Django changes, potential build method change etc) will likely cause significant delays to even our ability to build testing channel rpms, but as soon as we can again create half way workable rpms they will appear as updates within the testing channel. But I’m getting a little ahead of myself here.

To the summary of changes:

  • hide non functional auto update button until post re-launch fix. Fixes #2196 @phillxnet
  • avoid referencing incompatible subdir by-id device names. Fixes #2126 @phillxnet
  • add recognition of system disk & pool when on SD or MicroSD card. Fixes #2192 @phillxnet

The first of these was simply a removal, from the Web-UI, of a broken ‘enable auto update’ feature. We don’t want obviously broken stuff around in the Stable channel and I didn’t think we should delay our release and the much awaited new installer (awaiting the stable rpm) for what can, for the time being, be put on hold. Not quite the feature parity on that front but all in good time.

Then we have an issue reported from @bored_engineer re their advanced testing of our ‘Built on openSUSE’ variant on their big old Dell server with PERC/6i controller. This was a strange one but we got there in the end. Thanks again to @bored_engineer for their assistance and patience on this front. It seems our newer kernel/driver base from openSUSE was generating alternative by-id device names within a sub-directory that threw a spanner in the works. But we now ignore all these as a matter of course and have improved test coverage as a result.

Finally we have the very small. As some of you may have guessed, our pending new installer has a Pi4 target, an AArch64 machine, and during initial testing of this target, in real life, I found we failed to recognise microSD based system drives. But not any longer :slight_smile:.

So as indicated our focus is now switching to the final preparation of the new installer config with this or a soon to be released successor rpm pre-installed, along with all pending updates at the time of build. I will open a new thread requesting pre-release testing of this installer very shortly, directly after releasing the kiwi-ng config used to create it. But that is another story I will leave for that post.

I would like to thank all our testers for getting us this far; and if all looks to be OK with this 4.0 release rpm I will begin the Stable ‘Built on openSUSE’ channel updates by publishing the exact same rpm there also in a few days time. There after the testing channel updates are likely to be paused as we find our Python 3 feet with regard to our build system, but I hope there after to return to our documented release method once we are again able to build using the newer system we aim to update to.

Thanks also to our intrepid forum moderator and all-round contributor @Flox who has helped massively behind the scenes on our soon to be released kiwi-ng installer config.

As always ‘The Rockstor Project’ is almost entirely dependant on our Stable channel subscriptions for it’s continued existence in it’s present form. Subscribing to the Stable channel is a great way to support the project. Thanks again to our stable channel subscribers who keep all our Rockstor server lights on; in one way or another. As the current maintainer I am constantly looking for additional sustainable models for open source development but there are few examples that don’t involve out right sponsorship, which we don’t currently have. Do please feel free to make any suggestions you have on this topic by simply starting a forum thread as you see fit.

Enjoy …


Rockstor 4 Installer Recipe - now available

I’d just like to follow up on my:

Please see:

Enjoy some more …


Released 2nd August 2020

Stable Release Candidate 2

I am delighted to announce our second stable channel release candidate. We have had no reports of any show stoppers on 4.0.0-0 and we need to populate the Stable channel very shortly so this is both one of the largest and yet, at the same time smallest releases we can do. The aforementioned intrepid @Flox is solely responsibly for this one and I have resisted the temptation to slip any other changes in myself. That way we can still claim this release to have no intended functional change. Yet it changes significantly, syntactically, almost every single Python file in our entire project:

That is it. A massive undertaking that has cleared the way for cleaner pull request going forward that makes not intended change what-so-ever to our existing 4.0.0-0 release. But does serve to test upgrade from our recently released installer maker repo, previously post in this thread, once I’ve fixed that to it’s intended 4.0.0-0 rpm release. But I digress.

So do, as usual, report you findings re this rpm version as we are really hoping to promote this to the Stable Channel very shortly. And begin the much needed and much delayed process of moving to Python 3. A major element in formalising our python formatting as per this version sole focus.

Thanks again to @Flox for their sterling effort in this rather tedious, but necessary task.

So again, thanks for all testing reports, past and hopefully future and to our Stable Channel subscribers who make this entire venture possible. Please do consider subscribing to support our efforts as we enter our next stage of ‘Built on openSUSE’ releases and the inevitable performance and security enhancements that we get, and need, as we transition our entire technical ‘stack’ to something a little more modern on the version front.

Enjoy and on …


Released 14th September 2020

Stable Release Candidate 3

I am somewhat relieved to finally announce our slightly belated RC3 stable channel candidate. This one, unlike 4.0.1-0 has some functional changes / fixes over 4.0.0-0.

But first things first. I would like to thank @rssfed23 for their “all but the code fix” report on our failing public key authentication mechanism and @legion411 for their report on how our current 9000 Web-UI item limit fails with an NIS of 30,000 users. This latter issue may not yet be fixed but I’ve pop in a new limit of 32,000 and we can see how we go.

  • [NG] - Authorized_keys doesn’t allow public key ssh login. Fixes #2212 @phillxnet
  • 9000 user limit within NIS breaks Web-UI for larger user sets. Fixes #2211 @phillxnet

And as always I would like to thank the intrepid @Flox for their behind the scenes and here on the forum efforts. I’m afraid I was as yet unable to review another sizeable and exciting Rock-on/docker networking enhancement that @Flox has also submitted recently. I’m hoping to get this change in soon, or possibly once we establish our Stable release proper, we can have a very short testing phase followed by anther Stable release to accommodate this next big thing on the Rock-ons front. But we must, very soon, move to addressing some of our technical debt, and this will inevitably cause release delays and testing channel breakage. But let’s cross that bridge when we get to it.

For now, please test these releases thoroughly.

Leap 15.2 variant only - but x86_64 & Arm64

Please note: There are, and will likely only be, Leap 15.2 based variants from now on. Leap 15.1 is end of life in 2 month time and we need to focus our efforts; development, testing, deployment etc on a single distro, at least until Jump 15.2 is in Beta that is.

New Build Server note:

Also note that these rpms are the first to be build on an entirely rebuild build server built on a clean install of Leap 15.2, it’s predecessor had a 15.1/15.0 Leap heritage but prior to our re-launch we wanted to establish a clean build to ensure we didn’t have any magic configs hiding in the 2 years of config changes that last instance was exposed to. So just a heads up that we really need these rpms proven-as-good as if all is well I would be happy to move them over, as-is, to the Stable channel to finally offer that service in our new ‘Built on openSUSE’ guise.

So again, thanks for all testing reports, past and hopefully future and to our Stable Channel subscribers who make this entire venture possible. Please do consider subscribing to support our efforts as we are now in the final stage of the ‘Built on openSUSE’ Stable channel preparation.

Enjoy …



Released 9th October 2020

Stable Release Candidate 4

OK, so this time we are slightly early, to get back to the arbitrary monthly cycle betwixt stable and testing as we draw ever closer to the next stable release.

If there are no show stoppers I would like to promote these exact rpms (x86 and Arm64) released in our current ‘Built on openSUSE’ testing channel to the Stable channel as we really need to get that one started off and bar the elements addressed in this release we have had no other regression/show stopper reports of any kind. Plus it’s about time we offered a stable, as in not changing as rapidly and pre field tested in the testing channel option for all the folks who help to support this whole venture financially.

And so to the this time around:

In brief, and in order of application we have:

  • An NIS regression from our prior CentOS offering re NIS. It was broken, and is now fixed :slight_smile: Down to CentOS/openSUSE variations in file location and nature of NIS setup. Thanks to recent forum member @legion411 for initially building their own Rocsktor 4 installer and then reporting this regression. Much appreciated.

  • Next we have a basic house keeping event that removes, finally, our chkconfig wrappers/use. The above NIS change removed the last thing in Rockstor to use this. So the road was clear to get this old issue resolved by removing the then dead code.

  • And finally we have a partial fix/workaround for a massive slowdown observed in Chrome re Firefox in our smb admin user chooser. No issues in Firefox with large user sets (15k-30K users) but big slowdowns in Chrome. @Flox was instrumental in my arriving at this work around and any feedback on it’s new behaviour would be appreciated. In short we now search/match from the beginning of a user name not midstring. And searches don’t start until at least 3 characters have been entered.

I would like to thank our intrepid forum Admin/moderator @Flox for their background support roles and for continually watching my back.

And as always thanks to our supporters. Testers and Stable subscribers alike. I’m really hoping we are now at stable channel release stage as we have mounting pressure to bring this one home. And home for many, in this context, is a workable solution as well as a testing/development channel. Please all, review this release and inform the forum of any potential show-stoppers that may have been over looked. Otherwise I will press on in the next few days with, at last, the initial population of our ‘Build on openSUSE’ stable channel.

Have fun and happy testing.



Released 19th October 2020

Stable Release Candidate 5

So this one is a simple single ‘hot fix’ of our Stable Channel authentication mechanism. I had intentionally left the Stable repository empty (we were only at release candidate phase) and this in turn covered up a long standing issue with our use of zypper and it failing to cache the url embedded password. Many thanks to forum member @GeoffA for bringing this failure to light. After much ado and much help from both @GeoffA & @Flox in narrowing down exactly where the problem lay and getting an easy reproducer it turns out we need to both explicitly state our authentication mechanism, and not use the automated password caching system as it simply didn’t work in our python environment. Instead we have explicitly requested the use of a dedicated default directory for our credentials storage. This both adheres to existing zypper defaults and yet works around the requirement for a local environment for zypper that we simply didn’t have.

And so to the single item changelog:

Again, many thanks got to @GeoffA here on the forum for working behind the scenes with me and @Flox as we narrowed down and resolved this surprisingly tricky yet relatively simple in the end fix.


This one is a chicken and egg problem. If you are already subscribed to stable you will see this available (we use dnf to get pending changelogs) but you will not have working authentication to get it. Sorry about that.


Subscribe to Testing (they are, for the short Release Candidate phase parallel now) and update to 4.0.4-0 then change back to Stable.

Caveat: As 4.0.4-0 may well be our last Release candidate, then if you see a newer version and you wish to remain on stable (assuming it’s not listed below) you will have to install via ssh / console (not the Web-UI one):

systemctl stop rockstor
zypper in rockstor-4.0.4-0
systemctl start rockstor

I think there are very few folks on Stable in the beta (now RC) phase of testing the "Build on openSUSE’ so hopefully this will not be something that affects many.


Sorry to all those who have to jump through these hoops but we are still pre-release, just, so it looks like we caught this one just in time. Who would have thought there would be a spanner in the work at the last minute :slight_smile: .

I have update both repos with this version and will amend the default rpm installed by the DIY installer so from here on in this is the minimum recommended rpm version and we may even get to call this one a real Stable release and settle down to some much needed deeper development to head of some larger issue pending.


As normal I would like the thank all those who help to make “The Rockstor Project” possible and I very much hope that we can call this RC5 release our new official stable rpm. We all need both options as releasing direct to the stable channel is simply unsustainable but for now we need this fix surfaced. As usual keep the reports coming in and please be aware that we are now looking at show-stoppers only. If all works out I’m hoping for a short testing development phase after this so niggles and corner cases can be treated there before we again update the Stable channel. This is easier all around and fairer to those who help to support the project financially.



Released 3rd January 2021

Stable Release Candidate 6

We start the new year off with a slightly belated release of our next Release Candidate. In short this is a big one that includes multiple db schema updates.

Rocknets notes/issues

Unlike the last few releases this one includes a new feature, courtesy of the venerable @Flox, our intrepid forum admin: Rocknets. These are an extension to our Rock-ons that enables container level docker managed network capabilities, both auto assigned via Rock-on definitions (non Web-UI editable) and Web-UI configurable via the existing Rock-ons and Network Web-UI components. Rocknet documentation will be available shortly after this release and as already been submitted by @Flox himself. Please note that post enabling Rocknets and creating a custom rocknet, disabling the rock-ons service has a know issue with breaking the Web-UI Rockons page. The current work around is to re-enable rock-ons (docker). This issue is fairly well understood and should be address before our final Stable 4 release. See GitHub issue Disabling Rockons service breaks Rockons UI page post rocknet config · Issue #2239 · rockstor/rockstor-core · GitHub for developments.

@Flox and Myself had intended to delay this feature introduction until after the first stable 4 release, and to include it only in the subsequent testing channel but given our belated discovery of the AD/LDAP issues, also addressed in this release, and the scale of both code changes, it was decided that as we are still in the testing phase (with 4.0.4 as a stable repo placeholder only) we had an opportunity to re-define Rock-ons capability at the same time as moving to the 4 nomenclature. They-by establishing 4 on-wards Rock-ons compatibility for example.

Also note that due to a bug in our Change log display code, only one “Fixes” was listed for this rocknets addition. The following is more exhaustive:
Fixes #1982 #2003 #2013 #2009. Please view these links for attribution as the rocknets concept has been a long time in-the-making.

This degree of code change is not in keeping with a Release candidate phase but alas we are where we find ourselves with this one. And the accompanying AD/LDAP fixes / improvements, also by @Flox are likewise fairly significant but required for our intended feature parity goal prior to the first official Stable release of our ‘Built on openSUSE’ variant.

And so to the Changelog summary:

I would like to thank @Flox for once again ‘owning’ another release. This has pushed us very close to feature parity and dealt not only with a prior design short-coming in our docker plugin system (Rock-ons) but also fixed two of the more recently discovered issues with our ‘Built on openSUSE’ variant.

AD/LDAP notes/issues

N.B. (Reboot or rockstor service restart required post AD enable)
Nether @Flox nor myself are AD/LDAP experts and so the development of this enhanced capability, now resourcing the newer technology of sssd, is to be considered fledgling. However basic functionality has been proven and bar an issue where a reboot or rockstor service restart is required post AD enable (see, the functionality looks to be on par or better than our prior CentOS based offerings.


As always thanks to all our testers and stable channel subscribers. We are definitely nearing our next stable release, and although the AD/LDAP was a last minute surprise it was caught in time thanks to forum feedback.

We now need domain expertise to test what is available and comment here on the forum so that we might reach Stable release readiness. But please understand that we need to first establish relatively bug free implementations of the basics first.

Special thanks to forum members @HB7 and @Lorez85 in the following forum thread: Failed to Join AD Domain for reporting and assisting with the AD/LDAP issue to date. Much appreciated and invaluable to our efforts here.



Released 8th March 2021

Stable Release Candidate 7

Another slightly more belated release here folks. However we have quite the changelog/contributor list on this one. Only a single db schema update this time thought.

New contributors

I would first like to welcome, and thank, our 2 new contributors to the rockstor-core repo from which these releases are made: @StephenBrown2 who corrected an embarrassing number of my Readme updates during a most welcome pull request review; and @chrstphrchvz for a nice little speedup they developed while running on a Pi3 of all things. We only officially support Pi4 due to performance: we are just too slow on a Pi3, but as of this release as are just that bit faster on all systems as a result, nice. See the linked issue for the details.

Changelog summary:

As always I would also like to thank our forum admin @Flox for their work here on the forum and the major number of contributions indicated above. In this case centering again around AD/LDAP and rockons. Much appreciated. I think our AD/LDAP is now finally at feature parity or better than our now legacy CentOS variant. But we very much need testing on this area so if you have any experience / expertise in this area please consider testing this release as we would very much like to very soon move to our next Stable release and this depends on having more feedback on these complex part of Rockstor that have undergone quite the improvements.

We do have a rather large change in this release: and this one is down to me I’m afraid; and thanks to @Flox for the review/test. I’ve made a significant start on approaching our technical dept, and have now replace a completely orphaned element we depended upon for both our background balances / disk add / remove / raid change, and many rock-on operations. The motivation here was to not have a Stable release depending on something that we could no longer depend upon. Plus it was holding back our Django/Python updates so we had no choice really. There have also been some reports of our old django-ztask library failing folks in the field, thanks @freaktechnik. So we are now using Huey and it’s looking quite rosy. But as always this needs testing so please report your findings here on the forum so that we might assess our current status re the Stable release.


Thanks again to all those supporting this project with their time and attention in testing and via the Stable channel subscription. The Rockstor Project are very much a community supported endeavour and every little helps.

Please also note the following new Milestone:
First 4 Stable (ISO)

Test away and report rapidly as we work against the forces of kipple.



Released 10th May 2021

Stable Release Candidate 8

OK, so 4.0.7-0 is way more conservative than our last rather outlandish release of 4.0.6-0: around two months ago.

This one has contributions from our venerable and talented @Flox and from myself @phillxnet.

Apologies to @chrstphrchvz for not managing to review/merge a further potential speedup in our package management via
‘Use pkg_infos() to speed up rpm_build_info()’ #2287
This pr touches some rather sensitive code and for the limited speed-up reported it was deemed in need of a really good look prior to merging so it you do fancy reviewing this patch then please take a good look at this pull request. And/or possibly contributing some much needed testing in this area to prove no regressions result.

Changelog summary:

In brief, and in applied order

  • We had a regression in our ‘Built on openSUSE’ where our Web-UI log viewer was broken for dmesg. @Flox fixed via a clever work around.
  • There was a years long and unreported regression in honouring the ‘group management’ settings: found and fixed by @Flox.
  • And finally a rather trivial fix by myself where our ‘Built on openSUSE’ failed, in some cases, to recognised fake product uuid that would otherwise have been caught, a regression caused by our newer inherited kernels, via the new openSUSE base OS, using lowercase for their uuids/Appliance IDs. Thanks to forum member @nigel in the following forum thread for helping to diagnose this issue: Duplicate Appliance IDs Generated - #14 by nigel


Thanks again to all those supporting this project with their time and attention in testing and via the Stable channel subscription. The Rockstor Project is very much a community supported endeavour and every little helps.

Test away and report rapidly as we work against the forces of kipple and towards our first Stable 4 release.

Oh, and did I mention we now have Leap 15.3 rpms/repos!
And x86_64, ARM64EFI & Pi4 installer dev profiles to boot!
No; I don’t think I did :slight_smile: .

N.B. All rpms are built on the target OS; Leap 15.3 Beta in this latest case.
Special thanks to @Flox for invaluable help on the Leap 15.3 effort.





@GeoffA & @lexx



Released 18th August 2021

Stable Release Candidate 9

As per the previous release, this one is relatively minor, at least from the perspective of Rockstor code changes. But still contains 2 Rock-on related fixes (@DrC and me) and the continuation of package related code improvements/speed-ups from @chrstphrchvz (see Pi3 !! exploits in 4.0.6 notes above):

New contributor

I am chuffed to welcome yet another first time contributor, @DrC here on the forum who after much consternation and conjecture worked out that we were doing our Rock-ons refresh wrong, at least for slower network connections. We have recently move to https for our domain which also hosts the Rock-ons. But we had in place an http → https redirect. This added far more latency than I had imagined and resulted in failed Rock-on definition retrieval on slow connections. What a difference a character can make. So thanks again to @DrC for their tenacity in tracking down this rather unforeseen knock-on issue. Also thanks again for @chrstphrchvz for their continued efforts to speed/clean our stuff up. Much appreciated.

Changelog summary

The second Rock-on/docker related change is to re-enable IPv6 at the kernel level. We had originally disabled this early on in our “Built on openSUSE” endeavour as we have no ‘awareness’ within the Web-UI of IPv6. So disabling seemed like the way to go. However a recent Docker update and consequent fix (which has yet to be back-ported to our upstream) caused an abject docker (read Rock-ons) failure simply due to our less than common stance with regard to kernel level IPv6 disable. Thanks here to @sanderweel for tracking this one down and @Emmanuel_perez for the initial report. A very similar upstream docker failure was found from a few years ago, which helped to cement @Flox and my decision to throw in the towel on this one. I still think disabling IPv6 is the way to go, however we have to be pragmatic here so in order to bring us more in line with our upstream OS (openSUSE Leap) we have now removed this hard disable of IPv6. Note that a reboot is required post this install for the running kernel to be affected. But if you have a recent build of our installer then the ‘fix’ is already in place, see the following closed installer issue for more details:

Also a thanks to @Emmanuel_perez for reporting another potentially IPv6 disabled related issue regarding Teaming. Nothing proven yet but this also helped to sway our move towards leaving this still unmanaged network layer at least in a non disabled state.

General Thanks

As always a long standing thanks to @Flox for their tireless contributions here on the forum and in the backend buildbot mechanisms we use to build/test/publish our stuff. Also thanks again to all those supporting this project with their time and attention in testing and via the Stable channel subscription. The Rockstor Project’s continued existence depends on these support avenues and every bit helps.

Also note that as of this release we now have zero issues in our:

First 4 Stable (ISO) First 4 Stable (ISO) Milestone · GitHub milestone !!

So we may be looking at 4.0.8-0 as our first v4 stable release, fancy that. So please report your finding here on the forum so we can hopefully, finally, get our v4 Stable properly out the door, as we now have many pending issues (read technical dept) to address in our re-launch of the next testing channel which this time will be hosted in it’s own git branch. Time and tide and all that.

Test away and report rapidly as we work against the forces of kipple. And please check your Stable subscriptions if you have any ( :slight_smile:



Released 27th September 2021

Stable Release Candidate 10

This is the 101st version of Rockstor on GitHub: lets call it the Dalmatian release.


First off I’d like to thank all those here on the forum and out in the wider world for helping us get this far. Testers and stable subscribers alike. This is very much looking like our next Stable release so we can return, finally, to a dual delivery ‘model’ of testing and stable. Giving folks the option of a known good version while simultaneously having the freedom required in testing to develop the next Stable release on Python 3. This time around, due to the scope of underlying changes, via git branches: master for stable, testing for testing.

Almost no code changes since 4.0-8-0 but 3 fixes; bargain. First my apologies to @clink here on the forum who reported our log download fail; confirmed by @HarryHUK. Our rpm changelog is also processed by the Rockstor Web-UI and can only handle GitHub users. However credit is given in the linked GitHub issue.

We also have a new GitHub issue reporter azilber who helped in providing info on a know incompatible multi-drive external USB enclosure. And as always we have the venerable @Flox both here ‘out in the open’ and in the background for a timely fix to a timely report by @Hooverdan.

We are getting there now.

Changelog summary:

We have, ongoing, closed late beta end-to-end testing from installer to installed instance so please keep the reports comming. However only serious bug-fixes will now be considered for the stable release candidate, other fixes are very likely to be released as stable channel updates from now on while we get our soon to be branched testing channel into a workable state again post it’s pending, in-progress Django update.

Test away and report rapidly as we work against the forces of kipple. And please check your Stable subscriptions if you have any ( :slight_smile: Rockstor’s continued development and associated build and release infrastructure is dependant on multiple support vectors; and we hope soon to re-enable our Commercial Support option.



Released 11th January 2021

Stable Release Candidate 11 - Otherwise known as our first v4 Stable!!!

GitHub has now changed our count of releases! So we are again at release 84 !!
But given we are on the eve of HAL9000’s 25th birthday, lets adopt that as our reference here.

So this one has been a long time in development. Mainly as it’s been a tricky time for the core developers involved but we are here now. And this time has give us the opportunity to weed out the last of the fixes deemed necessary before our first v4 stable release. v4.0.9-0 just wasn’t quite there unfortunately.


As always and as an ongoing sentiment, I’d like to thank all update channel subscribers, folks here on the forum, on GitHub, and via support email, for making this a possibility. Feedback on where we are, from your perspective, is critical, and forms our main motivation on what to concentrate on. So as always, pick you flavour (update channel) and report away.

Special thanks to @Flox from myself. Our venerable core/docs/rock-ons/installer dev & forum admin has, as usual, pulled it out of the hat yet again. Despite having a greater work load elsewhere than normal.

New testing channel phase imminent

As stated in our last release we now need to move forward with our next testing channel phase. This is super important and can’t be put off any longer. We need Python 3 compatibility moving forward and that is a non trivial move. So do not continue with the testing channel if you intend to use, rather than develop Rockstor. It will be broken from a user perspective while we update the entirety of our code, starting with all the Django stuff. However: this exact same rpm (v4.1.0-0), baring any disasters, will be copied over to the stable channel shortly. And I intend to modify our installer to include this first v4 stable version out-of-the-box.

To the changes since v4.0.9-0

Changelog summary:

Most noteworthy here are the venerable @Flox’s config save import fix. @Hooverdan was again invaluable here with some impressively detailed and dogged reporting. Super important for our first v4 stable given the folks migrating over from v3 only once v4 stable was available. Other fixes are to critical bugs in email, NUT (UPS) function, Leap 15.2 → 15.3 dup updates, an improvement and likely speedup of disk serial rejection and some deprecation issues.

Since our last release we have also now re-done our Website in Hugo and have re-vamped and freshly populated our downloads page; full of pre-build installers. Be sure to also report on any typos etc with this central resource and remember it too is open-source via the following GitHub repo:

With all text now editable in mark-down curtousy of our move to Hugo. We also plan, over time, to add multi-lingual capability there.

Test away and report rapidly as we work against the forces of kipple. And please check your Stable subscriptions if you have any ( ) :slight_smile: Hot fixes of critical failures will follow in the Stable channel while we tackle the technical debt in the new testing channel.

Rockstor’s continued development and associated build and release infrastructure is dependant on multiple support vectors; and given this release we hope to re-enable our Commercial Support option shortly.