Inaccessible Files During Update

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:

(20/29): grub2-pc-2.06-70.el9_3.2.rocky.0.3.x86_64.rpm                                                                51 kB/s |  14 kB     00:00
(21/29): grub2-tools-2.06-70.el9_3.2.rocky.0.3.x86_64.rpm                                                            929 kB/s | 1.8 MB     00:02
(22/29): kernel-modules-core-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm                                                    895 kB/s |  31 MB     00:35
[MIRROR] nss-util-3.90.0-6.el9_3.x86_64.rpm: Curl error (28): Timeout was reached for                                                                                    /os/Packages/n/nss-util-3.90.0-6.el9_3.x86_64.rpm [Connection timed out after 30000 milliseconds]
[MIRROR] nss-sysinit-3.90.0-6.el9_3.x86_64.rpm: Curl error (28): Timeout was reached for                                                                                    _64/os/Packages/n/nss-sysinit-3.90.0-6.el9_3.x86_64.rpm [Connection timed out after 30000 milliseconds]
[MIRROR] nss-softokn-freebl-3.90.0-6.el9_3.x86_64.rpm: Curl error (28): Timeout was reached for                                                                                    eam/x86_64/os/Packages/n/nss-softokn-freebl-3.90.0-6.el9_3.x86_64.rpm [Connection timed out after 30000 milliseconds]
(23/29): nss-sysinit-3.90.0-6.el9_3.x86_64.rpm                                                                       632  B/s |  19 kB     00:30
(24/29): nss-util-3.90.0-6.el9_3.x86_64.rpm                                                                          2.7 kB/s |  88 kB     00:32
(25/29): nss-softokn-freebl-3.90.0-6.el9_3.x86_64.rpm                                                                9.9 kB/s | 305 kB     00:30
(26/29): nspr-4.35.0-6.el9_3.x86_64.rpm                                                                              858 kB/s | 135 kB     00:00
(27/29): nss-softokn-3.90.0-6.el9_3.x86_64.rpm                                                                       386 kB/s | 381 kB     00:00
(28/29): nss-3.90.0-6.el9_3.x86_64.rpm                                                                               1.2 MB/s | 704 kB     00:00
(29/29): kernel-headers-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm                                                         8.5 MB/s | 6.2 MB     00:00
Total                                                                                                                1.7 MB/s | 127 MB     01:15
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction

Is this bad? What do I do to remediate it?

Thanks for all help, Paul

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.
 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.

Could be mirror issues, you can try:

dnf clean all
dnf update

Thanks for the quick reply.

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                                                                                                    
[MIRROR] kernel-modules-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm: Status code: 404 for https://mirror.cpsc.u                                                                                                                                                                                                                  86_64.rpm (IP:
[MIRROR] kernel-core-5.14.0-362.18.1.el9_3.0.1.x86_64.rpm: Status code: 404 for https://mirror.cpsc.ucal                                                                                                                                                                                                                  rpm (IP:
(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.

See: as soon as you open your eyes rather than your mouth (pen) you understand what and why. So keep going !

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.