Bug 1903444

Hello, thanks for the report.

dnf reports two different errors but I think the "Failure writing output to destination" is likely caused by the ssl error.

Now the ssl error "decryption failed or bad record mac" can mean either the server certificate is invalid or the data were tampered with. The URLs work for me though. Can you still reproduce the issue? Are you using a proxy?

If the error persists for you, please share your dnf.conf and repository configuration in /etc/yum.repos.d

You can also try to move your dnf cache to a backup location (under root) and re-run the failing dnf command:
dnf upgrade  # make sure the command still fails
cd /var/cache/
mv dnf dnf-backup
dnf upgrade  # see if it works now

If this fixes it, it means there's a problem writing the cache data after all, in that case please share the cache you backed up. If it doesn't fix the issue, you can remove the backed-up cache.

Closing for inactivity, if you get back to this, feel free to reopen.

It's happening to me on Fedora 34 on a fresh installation. I reckon I was able to do one upgrade before the error started showing up. I tried to remove `/var/cache/dnf` and it solved the problem once. But now, after a successful `sudo dnf upgrade` it happened again and even if I remove `/var/cache/dnf` the error persists.

Let me know if I can help troubleshooting the problem and how.

Alessandro, if removing the cache helped once and didn't for the second time, it was likely a coincidence. Are you sure your error messages are exactly the same? Can you post it here? The error is likely to be an ssl error on the server. You can try a different mirror and see if it fixes it.

It's strange. The error was the same AFAIK. The following is exactly the output of my terminal (with a couple of irrelevant details overwritten).


> sudo rm -rf /var/cache/dnf/
[sudo] password for <username>:
> dnf info <package>
Fedora 34 - x86_64 - Updates                       26 kB/s |  19 kB     00:00
Fedora 34 - x86_64 - Updates                      1.6 MB/s | 3.3 MB     00:02
Errors during downloading metadata for repository 'updates':
  - Curl error (23): Failed writing received data to disk/application for http://mirror.in2p3.fr/pub/fedora/linux/updates/34/Everything/x86_64/repodata/7743e9a58367bbb0b6dc1b4bce8847410ae3dce892a0c2804ab3f6ad301c16ba-updateinfo.xml.zck [Failure writing output to destination]
Error: Failed to download metadata for repo 'updates': Yum repo downloading error: Downloading error(s): repodata/7743e9a58367bbb0b6dc1b4bce8847410ae3dce892a0c2804ab3f6ad301c16ba-updateinfo.xml.zck - Download failed: Curl error (23): Failed writing received data to disk/application for http://mirror.in2p3.fr/pub/fedora/linux/updates/34/Everything/x86_64/repodata/7743e9a58367bbb0b6dc1b4bce8847410ae3dce892a0c2804ab3f6ad301c16ba-updateinfo.xml.zck [Failure writing output to destination]


However on a second attempt it worked, i.e. it downloaded all the metadata again, asked to confirm GPG signature of additional mirrors, etc. I was then able to install the package without problems.

On a third attempt, it recalculated the fastest mirror (I have fastestmirror=True option set in dnf.conf), it resolved again to mirror.in2p3.fr and failed for the same reason.

So the theory its a mirror issue holds, but it still seems an defect somewhere in Fedora's broad package management system.

I checked every fedora repository specified under /etc/yum.repos.d/ and found it is configured with a metalink.
My understanding is that the metalink will return a list of healthy mirrors and the `fastestmirror` option will tell dnf to search the fastest among these. Therefore, if the selected mirror can't be used it seems a problem in dnf or the service that keeps metalinks up to date (it's a few days I'm seeing this failure).

Ok, so you are using not using ssl (the urls are http, not https), so that's out of question.

The second candidate here seems to be zchunk. You can try to turn off zchunk in your config file (zchunk=false) and see if that helps. Also check your dnf logs (dnf.log, dnf.librepo.log, hawkey.log) in /var/log/ if there are any other messages related to the error. (maybe attach the logs, ideally remove/backup them and then do a single failing run so that there isn't unnecessary noise in there).

And yes, seems the failures happen when the metalink picks the broken mirror. The likely cause is an issue on the mirror, which should be fixed. dnf should also fall back to a different mirror in these cases, but it's a limitation of the librepo library, it's not easy to fix and we have other priorities, unfortunately. We will address it eventually.

Ok, I'll try the suggested workaround and I'll look into the logs for further clues.

I understand there are priorities and I trust you're spending time where it's most valuable.

If this is indeed an issue, can you re-open it and note it also affects Fedora 34 so that it may be picked up in the future?

I fixed it with `dnf clean all`