I downloaded the latest iso and installed it onto my hardware. This resulted in Fedora 31 being installed and no Rockstor service. What is going on with this iso?
@Tony_Cristiano Welcome to the Rockstor Community.
Where did you get the download from?
Our still current, but very soon to be legacy ISO, is based on a now old CentOS version. And one would follow the āDownloadā link on our main web page to get it:
This in turn links to Sourceforge. Iām hoping to host our own Rockstor 4 installers once all is lined up ready. Once installed most upstream updates should be retrieved. Although the last version of Rockstor is 3.9.1-16 (testing channel) and 3.9.2-57 (stable channel).
Another option is our DIY ābuild you ownā Release Candidate Rockstor 4 installer. See the following GitHub repository for the instructions:
Hope that helps.
Hi Phillip,
Thanks so much for your prompt assistance. It turned out that Iām a total āidiotā, I had 2 USB sticks and somehow I managed to put the Rockstor iso on one USB and then installed from the other USB, which had Fedora on it. So sorry for the forum post.
A further question, how do install Rockstor 4? Can I use the iso install of 3.9 and download a new build or update it somehow.
I read the Rockstor 4 āBuilt on openSUSEā but I couldnāt follow it as I donāt use openSUSE.
Can you help with some clear instructions for installing Rockstor 4 please.
Tony
@Tony_Cristiano Ok that explains it. Been surprised myself similarly, and easily done, with multiple same make/model USB keys. Thanks for the update.
You canāt update any Rockstor 3 to a Rocsktor 4 as weāve moved to being āBuilt on openSUSEā where as previously we were built on CentOS. But we have had a recent contribution to the rockstor-installer repository by forum member @mikemonkers which very much looks like it will provide a cross platform, i.e. linux, mac, windows, way to easily build the installer. And our Configuration Backup and Restore procedure is intended to work across installs irrespective of Rockstor 3 or 4. Although using the latest available version of both versions is advised but not absolutely necessary.
Unfortunately, in keeping with the underlying theme of this thread, I made a silly mistake (didnāt follow my own instructions) and a silly omission (pressed the wrong button late at night in GitHub) so the review of this submission/contribution was incomplete. So itās inclusion in the repository has been delayed a tad. But once I find the time to re-do it should be merged/included in the standard repository and be ready to try. Out of interest, what are your available operating systems? As it will likely be helpfull for you to trial these soon to be merged instructions once they are done. @mikemonkers Looks to have tested them on OSX, not sure which version, and Iām in the process of testing them in linux.
So in short we are working on it and there should soon be more cross platform ways to make the installer easily. And apologies to @mikemonkers and yourself for my added delays in reviewing these changes. But once in Iāll update this thread with their inclusion so you can hopefully report on your test runs of the new instructions along with the operating system flavour and version you tired it on.
Hope that helps.
Iām a retired IT developer etc. I use Linux (Fedora 32 KDE) and Windows 10. Iād be happy to try out a build of Rockstor 4, although I need clear instructions for Fedora 32.
Tony
1 Like
Hi Phill
I tried to build a Rockstor 4 using all the instructions I could work out and I failed. I have the image-root.log file if youd like to see where it went wrong.
@Tony_Cristiano Well done for giving it a try.
Which method did you use? Because as of yesterday we now have an alternative approach submitted by @mikemonkers that uses vagrand and virtual box to abstract the creation of the required Leap 15.2 and then scripts stuff. This method should give us OS independance but itās only been tested on OSX and an existing Rockstor 4 instance so far.
The instructions are within the vagrant_env sub directory of that repository:
We have some outstanding doc formatting issues but the repository is under active development so we can see to those shortly.
This same Vagrant scripted method is also intended to work within Windows 10 but that is another, as yet, untested host OS.
Let us know how you get on. But do remember that this repo is being actively work on so things are changes as we go. But as of yesterday the resulting build by this alternative method does produce a workable installer but with the caveates indicated in the testing done prior to the pull requests merge:
Given that test was a Linux host itās nearest to your Fedora 32 requirements. So as long as you can install the pre-requisite Vagrant and VirtualBox it should also work for your Fedora instance. It essentially uses Vagrant to script the VM creation and run what the top level Readme suggest. With the indicated cosmetic caveats.
Hope that helps.
1 Like
@Tony_Cristiano Re:
OK, just fixed those, as they were caused by a trivial ommision on my part during the review process.
Also note that currently this method can only be used to build for x86_64. Our main readme method is still required for AArch64 profiles.
Do yet us know how you get on as we are keen to receive test reports on the build methods within the repository. And in your case, given the Fedora 32 and Win 10 possible options you would need an as yet undocumented approach for Fedora and an untested approach in Win 10. Iāll try soon with Fedora 32 myself here if I get the time. But Iāve first to merge our backlog of pull requests/ pending issues on that repo before Iāll have the time unfortunately.
1 Like
Great news: I got Virtual Box method to work on the first try on my Fedora 32 platform. Thereās one thing I think you should look at, that is it seems to have installed Rockstor 4.0.0 not the latest 4.0.1. I did a git clone and thatās what I got. Can I get that updated after I install it?
I tested the ISO and boots nicely. I will try an install from it tomorrow.
Cheers
2 Likes
@Tony_Cristiano Glad you got this sorted and @mikemonkers will be pleased to hear his now 2 day old method has been proven on yet another linux distro.
Re:
That is by design and fully intended. We have pinned the version of the installer (cosmetic mainly) in line with a recent pinning of the rockstor rpm version to 4.0.0-0. This way we have a build in test of the update system as there is no functional change between 4.0.0-0 and 4.0.1-0 as you will see in the Web-UI surfaced changelog once you subscribe to testing (we are very likely to promote the 4.0.0-0 & 4.0.1-0 from testing to the stable channel which is currently empty) so once you subscribe you should then be offered the 4.0.1-0 by way of proving that mechanism. But donāt leave any production machines on testing as it is expected to be broken again shortly after we start our technical debt marathon post populating the stable channel repository. We had to do this as otherwise we would be releasing an installer that had instantiated installs that had unproven update capability. So do try this out also if you are game.
Also keep in mind that when you build the installer it was made from all available updates at that time. So you may very well have zero or close to that number of available updates on the upstream side (flashing icon to the left of the āUses openSUSE linux ā¦ā bit in Web-UI header when any are found).
Thanks for the progress update and the Fedora 32 installer build confirmation and do let us know how you get on with the actual install.
1 Like
Good news again. The installer worked, it installed Rockstor 4.0.0 without any hassle. I really didnāt like the retro (90ās) installation screen and I realize itās probably temporary.
Once I had it running in the WebUI, I was able to update it to version 4.0.1 by connecting to the testing channel. That worked really well.
I also saw the indicator on the dashboard for Linux package updates, and so I did that too.
There is one issue I have to report and that is that my non-active disk drive does not go to sleep at all. This drive is not attached to anything. It use to sleep all the time in version 3.9.1 with the same configuration.
Tony
@Tony_Cristiano Re:
Thanks for the update/test and glad youāre now sorted with our latest.
Sorry but that is how itās meant to be, and it is in itās final form. As simple as possible with as few a choices as possible, and as fast and small as possible; hopefully. As per the doc entry we have for this process:
http://rockstor.com/docs/installer-howto/installer-howto.html
Our last installer was a generic one intended for all sorts of installs, but Rockstor is an appliance and needs very specific configuration. We had many instances before of folks doing all sorts of strange and incompatible configurations that would then land them/us in all sorts of trouble as we tried to work out what had been configured during in the general purpose installer that was simply out-of-bounds for what our Web-UI could cope with. We also had network configurations within the installer that would also throw our Web-UI and backend. This way we know what has been installed and configured as itās the same across the board: except for language choices of course. So again, sorry youāre disapointed with that bit. But at least itās simple and super fast and leaves no room for miss-configurations which was the aim here. We simply inherit the oem type installer from the openSUSE Kiwi-ng project and given openSUSE / SuSE use this exact same installer for some of their builds I think we are in good hands. Plus with zero graphical components we also throw out another whole family of issues we have had over the years with old/new AMD etc showing blank screens during a graphical installer. All far more disappointing that a < 5 min text installer that works and then we do all the rest in our familiar Web-UI. Plus we are fully functional before even the first reboot. Not many installers can say that 
.
OK, if you could start a new thread on this one with the exact make and model of you drive included and the exact settings you used previously and we can look to see if we have a bug in our āBuilt on openSUSEā variant or if itās just down to ādriftā in the utilities we use, i.e. there may just be a regression in the newer smartmontools or the like. But from memory we use hdparm to do our drive spindown settings but again we can check the details in a specific post focused on that specific issue.
Thanks for all the feedback and test and I hope you can live with our new not so shiny but super simple and super fast installer . And thanks for reporting your relative success in both building your own installer and using it to create the resulting Rockstor 4 install. We can now chalk up another win for @mikemonkers new installer method using Fedora 23 this time.
Just a quick note to your repo configurations. In the time between you building that installer and using it there was a fix to address refreshing the included repositories:
Issue:
Pull Request:
To refresh / fetch your own included repositories just run the following in a terminal as root on the Rocsktor instance:
zypper --non-interactive --gpg-auto-import-keys refresh
Newer versions of the installer do this automatically before creating the image to be installed but yourās will likely not have included that so running that single command as root once should put your included repositories right. It didnāt block anything but come the time for a distro update it may have come back to haunt us, hence adding it in the installer 23 hours ago now.
Hope that helps.
1 Like
@phillxnet, Regarding the repo key fixes Iām not sure if itās related but Iām seen this when I run your suggest command:
rockstorb:~ # zypper --non-interactive --gpg-auto-import-keys refresh
Retrieving repository 'Rockstor-Stable' metadata ....................................................................................................................................................................................................[error]
Repository 'Rockstor-Stable' is invalid.
[Rockstor-Stable|http://41734d56-dafd-c71f-e053-750d916e710a@updates.rockstor.com:8999/rockstor-stable/leap/15.2] Valid metadata not found at specified URL
History:
- [|] Error trying to read from 'http://41734d56-dafd-c71f-e053-750d916e710a@updates.rockstor.com:8999/rockstor-stable/leap/15.2'
- Login failed. (http://41734d56-dafd-c71f-e053-750d916e710a@updates.rockstor.com:8999/rockstor-stable/leap/15.2/content): The requested URL returned error: 401
Please check if the URIs defined for this repository are pointing to a valid repository.
Skipping repository 'Rockstor-Stable' because of the above error.
Repository 'openSUSE-Leap-15.2-1' is up to date.
Repository 'openSUSE-Leap-15.2-Non-Oss' is up to date.
Repository 'openSUSE-Leap-15.2-Oss' is up to date.
Repository 'openSUSE-Leap-15.2-Update' is up to date.
Repository 'openSUSE-Leap-15.2-Update-Non-Oss' is up to date.
Repository 'Shell Implementations (openSUSE_Leap_15.2)' is up to date.
Some of the repositories have not been refreshed because of an error.
@mikemonkers,
The error you see is because the stable branch in our Built on openSUSE flavor is yet to be populated; we only have testing rpms for the moment.
Now, as to why the stable repo was enabledā¦ Did you activate it from the webui? If not thereās something to elucidateā¦
2 Likes
Ah. That makes sense. Thank you.
I did enable it, yes. It my production server so I wanted it on stable.
I hadnāt quite appreciated it was unpopulated but thatās fine. It can sit there and await this.
2 Likes
Hereās my output:
PS I have created a new topic under Hardware category.
2 Likes
Just to confirm, I switched back to the testing repo and, of course, get a succesful pull like @Tony_Cristiano. Thanks again.
2 Likes