Fedora Account System
Red Hat Associate
Red Hat Customer
Created attachment 2106902 [details] journal Description of problem: As shown in the attached screenshot, whenever users run dnf install on a fresh installed system for the first time, it will throw out the quite confusing message, but if users run the same command again, it will work as normal lnie@fedora: ~ $ sudo dnf install NetworkManager-openvpn -y [sudo] password for lnie: Updating and loading repositories: Fedora 43 openh264 (From Cisco) - x86_64 Fedora 43 - x86_64 - Updates Fedora 43 - x86_64 - Test Updates Fedora 43 - x86_64 - Updates Error: dnf failed to write received data to disk/application for http:// Fedora 43 - x86_64 - Updates Error loading local metadata for repository "updates-testing" Librepo error: Checksum error in /var/cache/libdnf5/updates-testing-f60b6ae2260686-updateinfo.xml.gz: Unable to read zchunk lead lnie@fedora: ~ $ sudo dnf install NetworkManager-openvpn -y Updating and loading repositories: Fedora 43 - x86_64 - Test Updates Fedora 43 - x86_64 - Updates Fedora 43 - x86_64 Repositories loaded. Package "NetworkManager-openvpn-1:1.12.3-1.fc43.x86_64" is already installed. Nothing to do. lnie@fedora: ~ $ Version-Release number of selected component (if applicable): dnf5-5.2.17.0-1.fc43.x86_64 How reproducible: always Steps to Reproduce: 1.perform a default installation with Fedora-Workstation-Live-43-20250917.n.0.x86_64.iso 2. 3. Actual results: Expected results: Additional info:
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.