Yes, “… after reinstallation?” and channel subscription, and consequent update and (after a good 20 mins to allow for update to finish) reboot. That way you can be sure to get all the newest code prior to your import, config restore (if that is part of the plan). It’s a bit over the top but then at least you know any installer bug see:
and another example of the same thing:
which in the later elements of the associated issue have been tracked down to our upstream anaconda installer and it’s interplay with our kiskstart file:
root pool dev edit options non symmetrical · Issue #1848 · rockstor/rockstor-core · GitHub
or a miss step, accidental click, or failure to check for only one ticked disk, will likely wipe one or more data disks. Hence avoiding this completely by detaching the data disks. Just trying to play safe with data during large complex moves like a fresh install / re-install.
And just to re-emphasise, doc howto Reinstalling Rockstor is also worth reading and has a overview “Data Import” section at the end.
Good, then that narrows it down to the db migration mechanism.
I’ll try and pick this up again later, unless someone else beats me to it. @Flyer is up on db migration issues that we have had in the past and depending on timing may be able to step in here with some further diagnosis, if that is the way you end up going.
Also remember to detach all and re-attach all in the same sitting as booting up with at least one drive missing will also result in a failure to mount.
btrfs fi show
would also be helpful for those looking to help with this issue.
Hope that helps.