# Inaccessible Files During Update

**URL:** <https://forums.rockylinux.org/t/inaccessible-files-during-update/12922>\
**Category:** Rocky Linux Help & Support\
**Created:** [February 19, 2024, 2:22pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922 "2024-02-19T14:22:44Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![evenmoreconfused](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/evenmoreconfused/32/1806_2.png) [@evenmoreconfused](https://forums.rockylinux.org/u/evenmoreconfused)\
**Post date:** [February 19, 2024, 2:22pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/1 "2024-02-19T14:22:44Z")

</div>

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:

```auto
(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 https://mirrors.qontinuum.space/rockylinux/9.3/AppStream/x86_64 /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 https://mirrors.qontinuum.space/rockylinux/9.3/AppStream/x86 _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 https://mirrors.qontinuum.space/rockylinux/9.3/AppStr 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

---

<div class="post-metadata">

**Author:** ![evenmoreconfused](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/evenmoreconfused/32/1806_2.png) [@evenmoreconfused](https://forums.rockylinux.org/u/evenmoreconfused)\
**Post date:** [February 19, 2024, 2:48pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/2 "2024-02-19T14:48:18Z")

</div>

Separately, on a different VM (Rocky 9.3) at a different cloud service, I get:

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

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [February 19, 2024, 6:22pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/3 "2024-02-19T18:22:45Z")

</div>

Could be mirror issues, you can try:

```auto
dnf clean all
dnf update

```

---

<div class="post-metadata">

**Author:** ![evenmoreconfused](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/evenmoreconfused/32/1806_2.png) [@evenmoreconfused](https://forums.rockylinux.org/u/evenmoreconfused)\
**Post date:** [February 19, 2024, 7:19pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/4 "2024-02-19T19:19:02Z")

</div>

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:

```Transaction
========================================================================================================
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!

---

<div class="post-metadata">

**Author:** ![iwalker](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/iwalker/32/2599_2.png) [@iwalker](https://forums.rockylinux.org/u/iwalker)\
**Post date:** [February 19, 2024, 7:54pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/5 "2024-02-19T19:54:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![nouvo09](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.rockylinux.org/nouvo09/32/2920_2.png) [@nouvo09](https://forums.rockylinux.org/u/nouvo09)\
**Post date:** [February 24, 2024, 1:37pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/6 "2024-02-24T13:37:34Z")

</div>

> [@evenmoreconfused](#):
>
> 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.

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

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\
**Post date:** [April 24, 2024, 1:38pm UTC](https://forums.rockylinux.org/t/inaccessible-files-during-update/12922/7 "2024-04-24T13:38:11Z")

</div>

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