Upgrading Rockstor from a broken 3.8-14?

Hi!

I just borked my system by unknowingly upgrading from 3.8-14 to 3.8.16. :sob: According to this, what I should have done is upgrading to 3.8.15 first before upgrading to 3.8.16. However, when I do

yum list available rockstor --showduplicates

it only lists the following versions:

Available Packages
rockstor.x86_64 3.8-12 rockstor
rockstor.x86_64 3.8.16-1 Rockstor-Testing
rockstor.x86_64 3.8.16-2 Rockstor-Testing

Is there a repository where I can still find rockstor version 3.8.15, or am I doomed for a reinstall? Iā€™m on the testing channel BTW. Thanks!

@phillxnet @Flyer @suman are your people :*

Thanks @Tomasz_Kusmierz, I guess theyā€™ll respond when theyā€™re free :slight_smile:

As an update, I ended up working around this by nuking my PostgreSQL database:

systemctl stop postgresql
rm -rf /var/lib/pgsql

Then re-initialize the database by hand-executing the commands under sections [postgres-conf] and [postgres-setup] in buildout.cfg.

After these steps the rockstor service starts fine and prompts me to create a new user. Using the existing user turned out to be the trickiest part that required me to hack the rockstor source. It might have been easier if I just removed my existing user temporarily.

Hope this helps anyone else having similar problems.

It would be awesome if you could put it in more step by step solution - a lot of people pop up recently with this upgrade problem and I even didnā€™t knew you can just nuke database like that :confused:

I think the necessary steps should be all there for everyone who is comfortable enough with command lines to do that. I didnā€™t list the commands in buildout.cfg because it might be modified anytime in the future; so better just look at the most recent version. For anyone else with a mostly stock system, a clean re-install would be quicker.

And the showstopper of my system wasnā€™t even related to the database! Turned out the current version of initrock doesnā€™t like my network configuration and complains that the default interface isnā€™t configured. I still had to modify the source to get around that.

wait wait wait ā€¦ what ? please describe the problem with network interface (me sitting on the edge of the seat because he might have found an ancient bug that eluded us)

@Tomasz_Kusmierz Oops, didnā€™t think it was relevant to anyone else. The problem I had was that initrock.py looks for ā€˜default viaā€™ from the output of ip route, which does not match any of my interfaces. (Itā€™s actually ā€˜default devā€™ if thatā€™s what I think itā€™s looking for.) So I just hacked it to use one of my interfaces (which isnā€™t the default dev anyway.) Hope this helps!

< strikethrough > As an aside, nuking the database still turned out to be a PITA because Iā€™m left setting up all the services again :frowning: I still have the old database so hopefully someone chips in so I can upgrade temporarily to 3.8.15!< /strikethrough > So it turns out my old database somehow still works (of course I didnā€™t check first), and that that network interface bug was the only problem. Duh!!

I think that you actually found the problem ( seem from where I sit :smiley: ). Weā€™ve had a problem where

  1. if you would set up a teaming interface the system would fail to start (even with dhcp) unless you would add a normal interface with dhcp.
  2. system would not start if no cable was connected to any interface and there was no lease from dhcp -> system would timeout after ~10 minutes and only bailout was to log in through physical console and reboot it or use ā€œthe buttonā€

I did not engage with solving this any further because Iā€™ve had other stuff to do (donā€™t ask :/)

FYI Iā€™m having a Tennessee honey in your name right now :slight_smile:

Iā€™m not involved in Rockstorā€™s development so this may be wrong, but I donā€™t think initrock is invoked during normal boot. So if itā€™s the same bug maybe the code is duplicated elsewhere?

Might be completelly different script, but your scenario would explain why my systems didnā€™t get up when I was setting stuff in manual IP without gateway where there was not other interface with gateway in ā€¦ and I didnā€™t occur to me that route might be used as check ā€¦

Hi guys sorry for being late, but had 1)flu after Xmas 2)ā€œsoftware fluā€ (new laptop with win10 on default :sob: ā€¦it seems win10 not happy with some wifi cards, we started wrong way :rage:)

By jan 2nd Iā€™ll be back on my desk so probably will have those gigaupdates win requires, my linux dual boot :sunny: and all that code I hoped to have during these holidays!

Back to @haoto : performing a downgrade to 3.8-14 then back to 3.8-15 and finally to 3.8-16 should solve

Note: currently Iā€™m not sure if all of them had dot notation or minus notation

M

Really useful thread, sorry for chipping in very late. Thanks for your input @haoto. I think you are right about the initrock bug, and it does run on every boot ā€“ updating default interface part of it anyway. Weā€™ll get to it. Please feel free to open a github issue.

Regarding 3.8.15 not being available on testing channel, I just added 3.8.15.-1. I know this is too little too late for you, but others may find it useful. Typically, we donā€™t remove the previous major versionā€™s testing updates from the repo, but looks like I was a bit overzealous cleaning up.