Zypper lock on rockstor package

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.


@GeoffA Hello again and thanks for the report.

This is a known anomaly / timing bug. Re:

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.

Hope that helps.


@phillxnet thanks for your comprehensive explanation, which clarifies it completely for me.
I learn’t a lot there :slight_smile:


@GeoffA Your welcome.

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.



Yeah no worries, will get to that over the weekend.


Issues logged on github. I hope they are suitably descriptive, however I have linked to this post thread for clarification.