That post is way old but has some still relevant stuff in it. Mainly taking care not to overwrite a data drive by accident and the like. But given you are going to have to re-install you should definitely do this using our new v4.1.0-0 installer downloadable from there:
The most important thing is to make sure you don’t install by accident over a prior data drive. To ensure this we recommend disconnecting them with the system powered off. That way it’s impossible to install on them. And don’t leave the old system disk in place. Rockstor gets confused if there is more than one copy of it’s install in place at any one time.
So basically:
Do a fresh install of v4 using our installer to a new system disk when that disk is the only one connected to the system (to remove risk of data overwrite).
Then when the install has finished and you have finished the setup via the Web-UI, as per the how-to. Reboot to prove the resulting install is working over a reboot.
Then shutdown via the Web-UI and re-attach all the old data drives.
You can then import the new pool and do a fresh setup. Unless of course you have a config backup file. But you don’t mention this.
Hope that helps and do ask here if I’ve missed something. The new installer is way quicker and smaller so it shouldn’t take much time to try it out. We no longer release updates for our older CentOS based v3 and our v4 is now “Built on openSUSE” so we have active upstream btrfs improvements coming all the time. One of the main reasons we moved to openSUSE as it goes.
The one problem you may have is if you created any shares on your old system disk. As if it’s gone bad and you didn’t back them up then they are lost to the old bad system disk. Thought this depends on how bad it is of course. But given you are to use a new system disk and need to re-install anyway we can cross that bridge if it’s required. Generally the Web-UI discourages folks from doing this with a warning banner across the to. Also the new system Pool is now called “ROOT” not the older name of “rockstor_rockstor”.
Correct. This is required as some of the config-backup elements depend on shares, and so will fail to restore some of their elements if the associated shares have not been imported (via the pool import which brings in shares, snapshots, & clones).
Also note that older config save didn’t includes some elements that have since been added, like Rock-ons; and so they will not be restored. But if you install fresh ones, if you used any, and pick the exact same shares they used before, each should pick-up where they left off.
As a result of this thread and your recent question re order of config restore / pool import I’ve finnally gotten around to creating the following issue:
Once that is resolved the Web-UI itself should, as it should, afford this behavioural ordering .
I don’t want to include the import into the config restore as that would overload the elements of a system too much; and likely be way more confusing and ultimately less robust/flexible. So this way we keep them separated but indicate the one way dependency.
Just finished importing the pools and restoring my config. Everything worked fine and the system is up and running again. No loss of data, just loss of face for not looking at the system messages telling me the USB stick was going bad…
Thank you so much for the hand holding during the reinstall. And thanks even more for the quick responses to my questions. So to summarize, the support was excellent and fast!
Even though you are thanking me it occurred to you. You should thank yourself! It didn’t occur to me to suggest that, but it is a good idea. Thanks for opening the ticket for this action, it will definitely benefit anyone who needs to reinstall and it will save you from getting emails asking the same questions from people who don’t read instructions completely like me…