Unfortunately no, not as yet. I.e. no rpms produced and not repo setup for them, but latest stable has some initial code in place to resource a different rpm repo but it’s all still up in the air. I’m currently upping my game Jenkins wise so I can chip in more with our backend rpm rolling procedure with a view to producing rpms for openSUSE but that is not as yet ready. We also have a number of blocker issues that must be resolved before we start releasing openSUSE variants so still very much a work in progress.
The stable subscription transfer process from one machine to another is not nearly as painless as all concerned would like. It will involve you emailing support with your old and new application id and requesting your subscription be transferred. This is I know messy and we really need a self service web page of sorts but there isn’t one currently. Sorry for the inconvenience on that one and thanks for helping to support Rockstor’s development via the subscription. Much appreciated.
But there is good news re the appliance id re the future openSUSE move. It’s derived from the motherboard so a re-install on the same hardware, baring some caveats, should see the appliance id unchanged. So if you end up re-installing the openSUSE variant once it’s ready you should end up with an unchanged appliance id.
Hope that helps and sorry for the rather less than ideal current setup re appliance id transfer.
Given I’m having issues installing the newest Rockstor ISO to my new hardware, is there anything that might be a recommendation for installing Leap 15 for use temporarily that I might be able to later just lay Rockstor over top? If I install Leap and create a couple of virtual disks, one with spinning disk and one SSD, lay BTRFS on them, and export NFS from them, how might that be handled later by a Rockstor install potentially?
That’s a complex question as it would involve sketching out the current capabilities/limitations of Rockstors btrfs capabilities. And given you are obviously game to take a round about route, how about you try a source install of Rockstor on a generic (with some detailed config / package options) install of Leap 15.1. It’s now one of our intended targets in the openSUSE offerings (the other is Tumbleweed due to the cutting edge kernel / btrfs-progs).
There are 2 available references for this. It’s not for the linux beginner, but then you are obviously not a beginner, but on the other hand it’s also not that tricky either.
Big caveat is that it’s definitely at alpha stage, but if it works for you in the setting you have then great. And of course your input on what you find broken would also further the effort to move to openSUSE in the first place. Anyway I think it’s well worth a try as long as you are game to potentially jury rig a thing or two or three in the process. I’m currently working on backend infrastructure which in turn will enable the release of openSUSE rpms anyway and the current master branch can transition itself from source install to rpm install so when those testing rpms do become available that system should be able to convert in place to an rpm based Rockstor install. Although all settings (the db) will be wiped but that can be aliviated in part anyway via a config backup prior. Also not you will have to install via source NOT in /opt/rockstor. I suggest /opt/rockstor-dev.
Slightly more on topic is our developer centric wiki entry:
which give openSUSE specific instructions on how to do a source (developer) install of Rockstor.
You might also want to take note of all issues in the GitHub rockstor-core repo that begin with [openSUSE].
At least this way you should, once we have the openSUSE rpms rolling, transition over and also ensure that your btrfs configuration is consistent with what Rockstor can manage. Take note however that current master is what stable channel subscribers are currently using and this is not guaranteed to be the case with our initial openSUSE offering (though it is very likely).
Hope that helps and do bear in mine that that the openSUSE function is very much a work in progress. Also note that we are testing against Tumbleweed also so that might also be of interest if you also have install difficulties with Leap 15.1 (currently in beta and one of our targets).
Progress reports and pics most welcome, along with focused GitHub issues, and remember to specify [openSUSE] in their title if they pertain only to the openSUSE base.
I should be able to move back to this openSUSE move, code wise, once I have the back-end infrastructure project mostly underway.
I’m going to go ahead with OpenSUSE Tumbleweed, and see what I can do with Rockstor that way, to hopefully save some pain down the line.
Quick question though. In the dev docs it simply says “Build as usual, but not in /opt/rockstor” … What does that mean? I have multiple other applications I’ve built from git, none of which follow the same compile process. So what does “build as usual” mean?
@jcdick1 Hello again. I’ve already posted on your newer thread where you report getting further along than you were last in this thread but wanted to contextually address the following:
We already have in place in the master branch (latest GitHub rockstor-core) code that is intended to ease moving from a source install to an rpm one. This is actually intended for your exact predicament, ie apparently needing to install from source (on openSUSE in your case) but wishing in the future to have the ease of rpm install and it’s consequent smoother updates. That is why it states to not build in /opt/rockstor as that is the location of the rpm install. That way we can maintain the facility to have a source install move over to an rpm install. The intention is to provide a facility for those contributing to Rockstor via a source install to then revert to an rpm install once their submitted pull requests are then released via rpm. But it was also motivated to allow early adopters of our openSUSE source plans to switch back to rpm installs once they have been released.
My current project, in the background, is actually in standing up these additional rpm repositories and their associated infrastructure so that we might offer said openSUSE rpms.
By the way, a question for you. You deleted a post in this thread indicated that your install issues were down to hardware. Did you end up in turn finding out that they were in fact not down to hardware? Just wondering as if they were it would have been nice to know what hardware issue affected your install. Just curious and it may help others with similar hardware issues and how they ‘surface’ when installing as was your original issue in this thread.
Thanks and happy hunting for function on our very not quite ready yet (read alpha) openSUSE source build option. And remember that bug reports are always welcome, noting the suggestion that we tag all openSUSE specific issues with “[openSUSE]” as has already been established as defacto standard in our issues: