Bug 2396334

Proposed as a Blocker for 43-final by Fedora user lnie using the blocker tracking app because:

 seems affects:
https://fedoraproject.org/wiki/Fedora_43_Final_Release_Criteria#Installing,_removing_and_updating_software
though dnf  works well after a second-try,  the output is quite ugly, and I guess we should not release fedora with it.

I tried to reproduce the issue in the virtual installed from Fedora-Workstation-Live-43-20250917.n.0.x86_64.iso image, but without any luck. Is it still reproducible? Could it have been caused by a network / repository mirror issue?

The message "Error: dnf failed to write received data to disk/application for http://" is strange. I didn't find it in dnf5 nor librepo sources. There is similar message "Failed writing received data to disk/application" in curl, but it's not exactly the same.

Originally I thought that the cache in /var/cache/libdnf5 was somehow damaged right after the installation, but the cache does not exist on the freshly installed system and is created during the first run.

> Is it still reproducible? 

yeah, actually it's been there for a period of time, I think it doesn't affect any function, so I didn't report it.

And, you don't need to perform an installation to reproduce it, just play with live.

>Could it have been caused by a network / repository mirror issue?

Partially because the network speed, as I just checked,I'm not able to reproduce it with a high speed network.
But I'm not able to reproduce this with f42. 

>  but the cache does not exist on the freshly installed system and is created during the first run.

 yeah, Gemini told me to "sudo dnf clean metadata" and I got "Cache directory "/var/cache/libdnf5" does not exist. Nothing to clean."

I'm unable to reproduce this, works fine for me.

To me, this looks like some local mirror sending corrupt data, or data being corrupted during transfer.

-6 in https://pagure.io/fedora-qa/blocker-review/issue/1939 , marking rejected. We mostly agreed this looks like some kind of mirror issue. If it's more reliably reproducible for more people, we can reconsider (clear "RejectedBlocker" from whiteboard and mark as blocking "FinalBlocker" again).

> yeah, actually it's been there for a period of time, I think it doesn't
> affect any function, so I didn't report it.

If you can still reproduce the bug, would you mind sharing the contents of /var/log/dnf5.log as the error occurs?

You can clear old log messages with `sudo mv /var/log/dnf5.log /var/log/dnf5.log.old` and then perhaps

```
sudo dnf5 makecache --refresh --disable-repo='*' --enable-repo=updates-testing
```

If it's a problem with a specific mirror, we will be able to tell which one from the log.

Created attachment 2107343 [details]
dnf5.log

> If you can still reproduce the bug, would you mind sharing the contents of /var/log/dnf5.log as the error occurs?

yes, and sure, just attached it.

This could possibly be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2001386
Can you reproduce without zchunk? (dnf install hexchat -y --setopt=zchunk=0)

Checked on a fresh installed system, "dnf install hexchat -y --setopt=zchunk=0)" works.

Yes, this does look like https://bugzilla.redhat.com/show_bug.cgi?id=2001386. lnie, are you using a proxy server? If so, then we can probably close this as a duplicate and continue troubleshooting on 2001386.

yeah, after I unset the proxy, I'm not able to reproduce this bug. However, I see #2001386 is reported against f39,but I'm only able to reproduce this bug with f43,hmmm

*** This bug has been marked as a duplicate of bug 2001386 ***

Interesting that you can only reproduce on F43. Given that you're also using a proxy server, it seems to be the same bug though, or closely related. Closing as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2001386.