After my cloud provider required “emergency maintenance on the underlying hardware”, one of our VMs (running Rocky 9.3) is now back up and running its workload (apparently) properly.
While verifying its proper operation, I ran a dnf update and received:
Separately, on a different VM (Rocky 9.3) at a different cloud service, I get:
Last metadata expiration check: 0:00:17 ago on Mon 19 Feb 2024 02:44:51 PM UTC.
Error:
Problem: package fwupd-plugin-flashrom-1.8.16-1.el9.x86_64 from @System requires fwupd(x86-64) = 1.8.16-1.el9, but none of the providers can be installed
- cannot install both fwupd-1.8.16-1.el9.rocky.0.2.x86_64 from baseos and fwupd-1.8.16-1.el9.x86_64 from @System
- cannot install the best update candidate for package fwupd-plugin-flashrom-1.8.16-1.el9.x86_64
- cannot install the best update candidate for package fwupd-1.8.16-1.el9.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Surprisingly, on a purportedly identically managed sister server to the above, updates run happily to completion.
Tried clean all / update on the first box, it reports nothing to do.
Tried same on second box, the initial error no longer occurs, but now I get:
========================================================================================================
Install 4 Packages
Upgrade 22 Packages
Remove 4 Packages
Total download size: 123 M
Is this ok [y/N]: y
Downloading Packages:
[MIRROR] kernel-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm: Status code: 404 for https://mirror.cpsc.ucalgary. ca/mirror/rocky-linux/9.3/BaseOS/x86_64/os/Packages/k/kernel-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm (IP: 1 36.159.208.97)
[MIRROR] kernel-modules-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm: Status code: 404 for https://mirror.cpsc.u calgary.ca/mirror/rocky-linux/9.3/BaseOS/x86_64/os/Packages/k/kernel-modules-5.14.0-362.18.1.el9_3.0.1.x 86_64.rpm (IP: 136.159.208.97)
[MIRROR] kernel-core-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm: Status code: 404 for https://mirror.cpsc.ucal gary.ca/mirror/rocky-linux/9.3/BaseOS/x86_64/os/Packages/k/kernel-core-5.14.0-362.18.1.el9_3.0.1.x86_64. rpm (IP: 136.159.208.97)
(1/26): kernel-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm 10 MB/s | 4.8 MB 00:00
(2/26): kernel-modules-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm 50 MB/s | 37 MB 00:00
(3/26): kernel-core-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm 23 MB/s | 19 MB 00:00
(4/26): selinux-policy-38.1.23-1.el9_3.2.noarch.rpm 1.4 MB/s | 52 kB 00:00
(5/26): selinux-policy-targeted-38.1.23-1.el9_3.2.noarch.rpm 34 MB/s | 6.5 MB 00:00
I tend to think you’re right; it may be mirror or network issues, I will try again later.
I don’t understand how dnf is designed to deal with issues like failed module downloads. Running dnf update over again seems to always report “nothing to do”. Does this mean the new module got downloaded somewhere I didn’t see and all is updated? Or that the old module is still present but dnf isn’t noticing? Or something else even more worrying??
UPDATE: I now see that the failed modules in the first 3 lines did in fact get downloaded (from another mirror?) so all would seem to be well on box 2. And the same is true for my original post: the failed modules part way thru then succede in the following lines.
Nonetheless, I wish I knew when the occasional error and warning messages that pop up in dnf update were something I actually needed to worry about!
I’d more worry about the one suggesting the --allowerasing or --skip-broken, since using either one of those could potentially cause something to go really wrong. Sometimes those commands can work, but it’s really best to investigate what is going on before attempting to use them. I kind of think of them as a last resort type option.
If you cannot connect to a particular mirror, dnf will attempt anyway to connect elsewhere and download the files. Which it seems it did do in the last output you showed anyway. So it did use mirror selection to get it from somewhere else, so not a major thing to worry about to be honest. If you weren’t getting any downloaded at all, then that would suggest something bigger.