3.9.2-58
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:
- [NG] ROOT pool user share not displayed on page refresh. Fixes #2156 @phillxnet
- Update libraries needed for Rsync over SFTP. Fixes #2155 @FroggyFlox
- improve share rollback robustness re missing qgroup. Fixes #2171 @phillxnet
- improve pool import robustness re recently observed quota states. Fixes #2163 @phillxnet
- BTRFS SCRUB status reporting enhancements. Fixes #2162 @ubenmackin @FroggyFlox
- [openSUSE] Refer to full name of nfs-server.service. Fixes #2160 @FroggyFlox
- inadvertent use of internal -1/-1 pool quote group flag. Fixes #2158 @phillxnet
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.