Recently I attempted to update my OpenSuse Leap from 15.2 to 15.4. Somewhere along the upgrade, my previous Rockstor install got fudged and was no longer starting up.
As it was a src based install (sitting in /opt/rockstor), I first tried just rebuilding. But I believe the build system has switched over and changed due to python 2 vs 3. So I just deleted the whole directory, and did a fresh git pull, and then built everything.
The issue I’ve run into is my database appears to be hanging over from the last install, which was a few version behind. So all the data on past scrubs and snapshots are there. But if I try and run a scrub I get errors about IDs already existing. Same if I try and change a Share or add a pool. It’s almost as if the identity keys were reset on the database, but since I still have data it’s trying to do inserts and the primary key is failing.
At this point, I really just want to reset everything (db, code base, etc), to get back to a clean state. What is the best way to do this? Is it safe to delete the database (where is this located?) I’m assuming I’ll need to resetup various pieces, but some things should import (pools and shares mainly).
@kupan787 Hello again.
I can chip in a little here:
Yes, the db maintenance is a major pain. And as you say we have change the build etc. The rpms we build do carry some of our transitional work. If you fancy you can take a look here: remember that this repo, like rockstor-core and rockstor-jslibs also has branches that all need to match:
That’s very likely going to be the cleanest path as it goes. And I’d agree with taking this path given your source install history. Plus we have modified our build system in the interim.
Also, why not just take advantage of our testing rpms ?
Our raw code is often between known issues - we have to block things into manageable chunks, but we tend to release to testing when the smallest chunks are mostly in place. But do no mix rpm and source installs. Or you will end up where you are now again. Plus in the past we anticipated source installs being seperate: however we no longer support a source install as such. But if you take a look at the above repo you can see exactly how we do our install anyway. Via Poetry now as it goes, along with a likely overloaded build.sh script. And some juggling of moving goal posts as usual with these things.
The above procedure details in the dev docs drops the db and starts from scratch: hence no knowledge of anything before hand: hard-reset. But with this you will encounter a clash with existing system users such as the one that backs your old ‘admin’ user for the Rockstor Web-UI: all in that dev doc as it goes. Nothing special about this use so if you want to re-use it just wipe form system before you re-do the Web-UI setup screen.
Yes, plus if you have sufficient function currently, you could try the config-backup and restore approach. But with your existing db being essentially out-of-scope you may end up getting more agro than just re-configuring from scratch.
Given your’ve already managed a source install: I’d suggest you take our rpm testing route. Add the repo and install (with non-existent /opt/rockstor) and it should serve your far more reliably than duplicating the work our testing channel already does re feedback from folks for known source release points (which is essentially what our testing releases are).
See how you go, and let us know. And be sure you have an active Postgresql 13 server with alternatives set to this specific version before you make any moves. The rpm scriptlets during install/update/uninstall etc ensures such things. And remember we have two streams here across many repos stable (master branch) and testing (testing branch).