We quite recently had an issue with some yet undetermined connectivity issues. They now are resolved, but only by rebooting the main firewall and internet-facing router. We still don’t know what the issue actually was, but (at least) DNS and IMAP services were behaving very weirdly.
However, in trying to determine the problem, a dnf update was run on our main email server*. It reported 4 packages to install, 288 to update, and 3 to remove**. This seems very excessive, as I believe it was last updated Sept 21st (yes, I know that’s too long between updates).
But my question is this: generally the mail server is managed using cockpit, which showed, and still shows, that “The system is up to date”. Why does dnf update show nearly 300 required updates, and cockpit show none?
Thanks for all help,
Paul
When this happened, it’s not clear whether or not the internet connectivity was up, down, or only partially so. dnf did not report any trouble getting the updated repo contents, but many internet requests were doing weird things from every host in our internal systems at the time.
** There are many unlikely / infrequently updated packages shown, including rsync, tar, yum, which, and many other things that should have been stable for years.
Sorry, forgot to mention that this is Rocky 9.0 running iRedmail server. Also didn’t make clear that I have not let this large quantity of updates actual happen yet. They are still all listed as required, even though internet connectivity is fully restored.
Did I miss some event where every second package in all Rocky required updating?
I’m failing to understand the problem here. My minimal install has 435 packages, therefore an installation with iredmail, etc, etc is most likely to have near 500 or more if a graphical desktop was also installed. Assuming even 300 packages to update, that’s only 50% of a minimal install. So what is the problem exactly? Updates are released, whether one time you check there are 5-10, and another time when there is 300 what’s the difference? Soon will be 9.1 and then pretty much all packages are most likely to update.
September to almost end of November is quite some time, and for me perfectly normal to see that amount of updates. Let’s compare Fedora, where there can be 200-300 every few days. And yes I realise, Fedora is bleeding-edge so it’s gonna have that amount of updates very regularly. But for RHEL/Rocky or other stable distributions, this is perfectly normal.
For comparison, I have a AlmaLinux 9 desktop that has now 1561 packages. The 9.0 → 9.1 did alter 542 packages.
Between Sept 21 and the 9.1 update there were about 130 update events for Alma 9.0.
Rocky and Alma should release about same amount of updates, since they both source RHEL.
If some package is updated frequently and you do run dnf up often, the dnf history will show many updates, while if you run only once, that adds only one to the count.
If one has third-party repos, has many packages installed from them, and repo releases updates for many, that adds to the count.
Cockpit, PackageKit, dnf … at least some of those do cache repo metadata and caches can be stale.
Example: I log in, Gnome says: “There are updates”, I run ‘dnf up’ and then log out. Gnome asks at that point: “Do you want to install the updates?” Clearly, Gnome has cached data that call to ‘dnf’ did not refresh.
Therefore, caching can explain some differences on what tools do show.
What I found in cockpit on my RL8 system is that the Overview panel will say that I’m up to date. But, if I scroll the left hand tool bar down to software updates and open that panel then it will seem to find that yes there are updates to install. Another thing, if you want cockpit to keep track of all updates you have to do them via the cockpit interface. If you do it by sshing into the box then cockpit won’t see those updates.
Sorry, I should have better organized my post. The issue at hand is the discrepancy between the cockpit and dnf update views regarding pending updates. I mentioned the large number of updates pending in the latter (and the original office-wide weird connectivity issues) only as unusual and unexpected events, in case anyone recognized either as a cause.
Yes, thanks, I do know that these two places in cockpit can say different things. The Software Updates panel in the lower left is where it was saying the system was up to date. It eventually caught up and started showing the same 300 or so required updates (see below).
Okay, so two days later the required updates do show up in cockpit as well. Not sure I understand the difference in the mechanisms behind the two approaches (cockpit vs dnf).
I am sorry to have to report that I apparently lied. It now reports to be running Rocky 8.7. Either it was improperly upgraded to 9 and has now somehow reverted to 8.7, or it was never upgraded to 9 in the first place (we updated most of our servers to 9 a few months ago – perhaps we omitted this server because it’s mission critical).
If so, then the large number of updates makes sense as I guess it’s part the 8.6 to 8.7 process??? Is that supposed to happen automatically without us asking for it?
The repo definitions do use ‘mirrorlist’. URL for the mirrorlist server that will centrally give URLs to 8.7 repos (once they are released) even though your request still has $releasever with value 8.6.
Effectively the repo content is replaced.
The entire idea is that your package manager installs/updates what is available and only the latest released content is available. The updates are “seamless”. Sure, there are more at a time, with more feature updates – the interim, sporadic updates tend to focus on bug and security fixes – and the Release Notes might have important points.
Rocky does not have access to EUS content. Therefore, the moment 8.7 was released the 8.6 content became unsupportable. What is in repo now (8.7 content) is the latest and best for Rocky 8.
If you have automated the updates, then you have chosen to say ‘yes’.
I see. Seems fairly reasonable from where we are sitting (i.e. that works for us).
One question: if I just let all these new packages install – either with automatic updates or manually – is 8.7 then fully and correctly installed? Or do I have to run some additional script thingie?
In general, Rocky was already installed correctly, and would continue to be after the update and a reboot. That’s the big advantage of Rocky, you can apply huge number of updates from the official repos with very low risk.
The premise of RHEL is that one can set up and configure a service and then run with it a decade without tweaking the config. Couple times there has been an exception, where update required change in config.
If one has third-party content, then there might be considerations.
Recent example: timing of Qt update in distro and updates of Qt-dependent packages in EPEL.
Common example: driver updates, like NVidia’s, which depending on source are more or less automatic.
In order to guarantee the stability of your systems , I highly recommend to use patch management tool like Uyuni (upstream for SuSE Manager)/SuSE Manager(Spacewalk-based) or RH Satellite (catelo + pulp + a lot more open source projects).
It will give you a fine grain control over what you push to the systems.
Here is a real-world example why you need such.
Imagine that you have a RHEL 8.2 system running third-party (vendor supported) software.
You can’t update as you will loose support.
If you wish to install any additional package and that has a dependency to glibc, systemd, dbus, etc - then the last version of the package will force an update. You will have to find which package version is OK with current glibc/systemd/dbus .
If you use patch management - the system is locked on 8.2 and you can install additional packages fully automatic (for example via Ansible) without worring of updating glibc or any other critical component.