Web UI no longer informs about available updates

tachikoma · November 17, 2025, 5:35pm

I run Rockstor 5.1.0-0 on my server.

In the second line of the header, which is shown on each page, it says on the right-hand side:

Uses openSUSE Leap: 15. Linux: 6.4.0-150600.23.73-default

It used to be the case, for a a few months after install, that a little WiFi/radio-like symbol would show up left of this when there were updates to be installed. Clicking on it opened a modal that would allow me to trigger the installation of updates.

This no longer works automatically now. Apparently available updates are not getting refreshed

I’m not seeing anything unusual in my /var/log/zypper.log, nor my /var/log/zypp/history, but the latter hasn’t been written to since 2025-10-21, which may be the last time I installed updates, although I don’t recall whether that was via CLI or WebUI.

systemctl only shows one failed service, which is clearly unrelated:

● dmraid-activation.service                                                                   loaded failed failed    Activation of DM RAID sets

( I don’t have any DM RAID sets, so I’m not bothered by that.)

There’s no service I can see that would run a periodic zypper refresh or anything like that, but I assume that there must be something like that, which is not running correctly, but I don’t know where to look and how to debug it.

To test this further, as I was writing this post, I ran zypper ref a couple of times and it finished successfully. After that zypper up showed that there actually were some updates to install:

# LC_ALL=C.UTF8 zypper up
Loading repository data...
Reading installed packages...

The following 3 package updates will NOT be installed:
  dracut-kiwi-lib dracut-kiwi-oem-dump dracut-kiwi-oem-repart

The following 56 packages are going to be upgraded:
  bash bash-sh bind-utils binutils chrony chrony-pool-openSUSE cifs-utils cyrus-sasl cyrus-sasl-gssapi cyrus-sasl-plain docker dracut-kiwi-lib dracut-kiwi-oem-dump dracut-kiwi-oem-repart elfutils krb5 krb5-client krb5-devel libaio1 libasm1 libatomic1 libctf-nobfd0
  libctf0 libdw1 libelf1 libfreebl3 libfreetype6 libgcc_s1 libgomp1 libitm1 liblcms2-2 liblsan0 libreadline7 libsasl2-3 libselinux-devel libselinux1 libsoftokn3 libsolv-tools-base libstdc++6 libxslt-devel libxslt-tools libxslt1 mozilla-nss mozilla-nss-certs ntp openssh
  openssh-clients openssh-common openssh-server perl-HTML-Parser readline-devel runc smartmontools vim vim-data-common xen-libs

The following 7 NEW packages are going to be installed:
  docker-buildx perl-Encode-Locale perl-HTTP-Date perl-HTTP-Message perl-IO-HTML perl-LWP-MediaTypes perl-URI

56 packages to upgrade, 7 new.

Package download size:    69.9 MiB

Package install size change:
              |     296.4 MiB  required by packages that will be installed
    74.9 MiB  |  -  221.6 MiB  released by packages that will be removed

Backend:  classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y): n

And after this, when I force-reloaded the current page with Ctrl+F5 the little WiFi/radio-like symbol finally showed up and clicking on it opened the modal and I was able to trigger the update installation (which now seems to be running normally).

But I’ve been here before and I fully expect that the next time update are available the little symbol won’t return again and I’ll have to run zypper ref from the CLI again… and at that point, I might as well just update only via CLI and not rely on the Web UI, at all.

Hooverdan · November 17, 2025, 5:50pm

This might be related to this issue here:

github.com/rockstor/rockstor-core

Package management: pkg_updates_info: Low max_wait: int = 15 leads to frequent logged error messages

opened 04:33PM - 25 Sep 25 UTC

Hooverdan96

On version 5.0.15-0 I frequently observe the below timeout error message in the …`rockstor.log`: ``` ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds ``` The default timeout for `zypper` itself is 180 seconds. from `/etc/zypp/zypp.conf` ``` ## ## Maximum time in seconds that you allow a transfer operation to take. ## ## This is useful for preventing your batch jobs from hanging for hours due ## to slow networks or links going down. Limiting operations to less than a ## few minutes risk aborting perfectly normal operations. ## ## Valid values: [0,3600] ## Default value: 180 ## # download.transfer_timeout = 180 ``` This also seems to happen when there are not really that many updates to process. Roughly timing within an interactive session, zypper spends most of the time in refreshing and preparing the repositories vs pulling the actual updates, which is probably highly dependent on internet connection/package server performance. While this is not a critical error (should this really be a warning rather than an error) the suggestion is to increase the timeout. Now, should it be 180 seconds, I don't know. If it's meant to highlight a possible bottleneck in package management (especially due to a large backlog of unapplied updates), maybe moving it up to half the default timeout (i.e. 90 seconds) might be a better choice. Open to suggestions or other opinions, especially if I misunderstood the intent behind the 15 second timeout.

Not sure whether you’ve also seen those error messages in the rockstor log, though. In any case you can expect that this setup will likely change a bit (whether it’s by implementing the asynchronous Server Gateway Interface (ASGI), or other changes) to help the above to be successful.

I assume, if you run at the CLI you’re running something like

zypper ref && zypper up –no-recommends

to exclude “recommended” packages but focus only on essential dependencies, unless you are looking for some of those recommended one.

yes, I believe that’s also a legacy setup, since that functionality is not being used, but solely focusing on btrfs RAIDs not using dmraid.

tachikoma · November 17, 2025, 6:09pm

Ah, I think you hit the nail on the head there, @Hooverdan!

Yes, I do, actually! It had been rotated already, so it was in my rockstor.log.1, but sure enough:

> grep "timed out after" *
rockstor.log.1:[17/Nov/2025 15:24:25] ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds
rockstor.log.1:[17/Nov/2025 15:54:41] ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds
rockstor.log.1:[17/Nov/2025 16:24:57] ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds
rockstor.log.1:[17/Nov/2025 16:55:13] ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds
rockstor.log.1:[17/Nov/2025 17:25:29] ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds
rockstor.log.1:[17/Nov/2025 17:55:45] ERROR [system.pkg_mgmt:575] Consider applying updates to reduce backlog: Command '['zypper', '--xmlout', 'list-updates']' timed out after 15 seconds

So it’s a known issue. That’s fine, then.

Yes, that’s what I would do – and probably will, every now and then, until the issue is resolved.

It’s not a big deal, I feel at home on the command line, but I was wondering why it stopped working in the WebUI.

As for that one failed service:

OK, can I just disable the service, then? Should be safe right?

Hooverdan · November 17, 2025, 6:43pm

I don’t know. @phillxnet can probably shed more light on this.

Hooverdan · November 17, 2025, 6:54pm

Upon reading more, I think it actually is a system service that comes with OpenSUSE itself by default, scanning for RAID configs on the disk(s) and not something introduced by Rockstor

Flox · November 17, 2025, 8:32pm

Yes, exactly that, and safe to disable on a base Rockstor installation.

tachikoma · November 18, 2025, 2:00pm

OK, done!

And now systemd no longer thinks my system is in a degraded state.

Thanks a lot!

John1 · December 17, 2025, 3:46pm

Perhaps if there’s nothing vital and it’s not aimed at being used going forward maybe not included in the standard install by default. That way you don’t get its log entries spammed into the system’s logs.

Namely the dmraid-activate.service entry.