I had a strange experience when updating my test install of Rockstor from 4.0.9 to 4.1.0 (testing channel) today:
Used the webgui to start the update, its started fine, then when finished it was still on 4.09. I tried this twice with the same result. Even a reboot did not overcome this.
I then SSH’d into the instance, and zypper up --no-recommends told me there was a zypper lock on rockstor package (not my doing, I hasten to add), thus it would not update.
zypper rl rockstor removed the lock fine.
And I was then able to update via the webgui successfully.
Not sure where the zypper lock came from, very strange.
My live instance of Rockstor updated fine the other week.
When you refresh the dashboard it kicks off a zypper refresh which in turn locks the zypper database. It was most likely this that was holding things up. It can often be seen as apparently spurios cpu activity as we trall through all the package changes etc and refresh whats available as an update. Once that process is finished the lock will be dropped.
The lock on the rockstor package update is also intentional and is done by the little wifi like icon to update all but the rockstor package. This allows folks to update everything but the rockstor package but it will still ‘show’ the rockstor package as an available update. We basically lock that package and do a system wide update then unlock it to allow for this all-but-rockstor update mechanism to help folks on testing update without breaking their system with an inadvertent rockstor package update.
Take a look at this file’s contents and specifically:
We basically programmatically write a shell script to do our bidding and then use the AT command to execute it “now”. This way we jump outside the Python constraints/env and fire off a regular thread in the OS. This in turn does the addlock “pkg_update_all” and removelock magic.
That file should contain all our packaging stuff and we currently have to use both dnf for our uninstalled changelog retrieval parsing and Web-UI presentation (because zypper can’t do this!!) and zypper itself for all the actual changes, updates etc. I really hope to move wholesale to zypper when it can give us pending package update changelogs but all in good time. Don’t be tempted to do any dnf yourself by the way. It’s not got a handle on the entire system. But zypper does.
What we are missing here really is better feedback on package state; lock wise etc. The wifi icon does change it’s mouse-over tooltip text to indicate package updates are on-going or the like but then often seems to disapear mid-update. I think we need something akin to our missing pool member notifications that flashes and is based on say a zypper process actually running, or maybe the precescence of the lock file alone should be enough. That would be more robust than what we have. It could then server to explain this apparent overlap of user initiated update and automated checks. We should also make nicer on the initialization feedback. So if a lock is found when a user package request is enacted we say hold-you-on-there.
Given you’ve reported here on this, if you fancy making a couple of feature requests in GitHub on the above we can hopefully drop these into our next texting channel development cycle as it’s definitely a fragility on the user experience/feedback front and a 1. header notifying zypper lock and 2. Web-UI feedback if one requests a package update (rockstor or other) we check first to see if the lock checker is happy to proceed and feedback to the user if it’s not. That may be a nice couple of issues for someone dropping in to have a crack at.
As always thanks for your feedback and prompting on such things. And let us know here if you make those issues, no worries otherwise as me or Flox can script them as time allows. These would be nice to haves and I’m looking forward to tending to this type of thing but we still have a lot of basic leg work to get us going on this next testing channel. More on that in it’s pending forum thread.
I think @phillxnet already outlined that the package is shown in the update list, but will not actually update (meaning one has to use the “Software Update” page to get that accomplished. Unless I am interpreting this incorrectly here:
Yes, this is by design. And I like it this way myself. Plus if we do remove it we are also obfoscating the fact that there is a rockstor package update available. That would be a backwards step in my opinion. Having it still show after an update for examle highlights the fact that it is still available as an update. If folks ‘learn’ only the one update method they may never be prompted (afordanced of sorts in Psychological terms) to look any further and be falsly assured that they have ‘all’ update in place. Plus this behaviour is entirely documented here:
And this update method was specifically added to do exactly what it does currently. We are not responsible for all non-rockstor updates as we depend entirely on our upstream for them: as such they MUST be independently addresable as we do here. Rolling in our channel (git branch) orientated updates as well looses us the oportunity to surface stuff like:
and:
Which he explicitly display via surfacing rpm changelog entries when folks use the dedicated ‘rockstor’ package update: which we are responsible for. Ergo separation of concerns and affordance to ‘look further’. Both methods are well documented but there are always improvements to be had.
We have to be super careful here that we are not seen to offer others updates under our own channels arrangement. And this specific update-everything-else method was specifically added to address this. And to allow folks to update every other part of their system irispective of what-ever channel they have selected with us.
Hope that helps, at least in clarifying the intended separation of these methods. We are hugely dependant on our upstream - and we in no way want to limit folks ability to update components not under our jurisdiction as it were. When folks find this method and notice it fails to update the ‘rockstor’ bit they are inclined to look further - they are in a sense informed pre docs. And thus likely to look to the docs or ask here on the forum. The up-arrow mechanism against our ‘name’ is still there (Prime Position) but dual prompts are likely better than single ones. Especially for newer users.
We distribute installers, yes; but we are entirely as-per upstream other than what our package re-configures (which is quite a few things) however all other packages bar systemd preferences defined in our OBS package we adapt to. That keeps us as close to upstream as possible.
We are sort of grave digging this thread here I think. As to me it looked to have been entirely resolved.
Maybe we need to implement a policy of locking threads such as this that appear to have been concluded now we are attracting more users? @Hooverdan as forum moderator I would defer to your judgement/decision on that front.
