Description of problem: dnf crashes with a segfault when zchunk metadata is used Version-Release number of selected component (if applicable): librepo-1.9.6-1.fc30 How reproducible: Always Steps to Reproduce: 1. Run dnf update Actual results: $ dnf update Fedora Modular 30 - x86_64 - Test Updates 1.4 MB/s | 2.1 MB 00:01 Fedora 30 - x86_64 - Test Updates 2.7 MB/s | 11 MB 00:03 Segmentation fault (core dumped) [ === ] --- B/s | 0 B --:-- ETA Expected results: dnf update works Additional info: librepo-1.9.5-1.fc30 works perfectly This is affecting Rawhide compose too: https://pagure.io/dusty/failed-composes/issue/1773
PR to fix the bug at: https://github.com/rpm-software-management/librepo/pull/148
FWIW, it looks like the bug was introduced in https://github.com/rpm-software-management/librepo/commit/3549e61bd34213b421c49f942db2576d327ca1c5, where h was changed to target->curl_handle for everything except the zchunk code, where it was instead set to target->handle.
*** Bug 1694653 has been marked as a duplicate of this bug. ***
*** Bug 1694643 has been marked as a duplicate of this bug. ***
Jaroslav, thanks so much for merging the PR. Will we be getting an update in F30 and Rawhide today or tomorrow? Thanks!
Hey, not meaning to be pushy, but can we please get this built today? We've had to shut off zchunk metadata on the F30 updates repositories until this gets fixed, and we're running late enough that it might have already pushed the feature back to F31.
Jonathan, if you open a Fedora PR, I'll gladly review, merge and build as a provenpackager.
Anyway, I consider this urgent if we want to do this today. Setting the severity accordingly.
(In reply to Miro Hrončok from comment #7) > Jonathan, if you open a Fedora PR, I'll gladly review, merge and build as a > provenpackager. Too late: https://src.fedoraproject.org/rpms/librepo/c/0cc00ce9db0470cce915c4562a342d385732d3fd?branch=master
Yes, I am making the build right now.
The builds are running: https://koji.fedoraproject.org/koji/buildinfo?buildID=1241140 https://koji.fedoraproject.org/koji/buildinfo?buildID=1241141
librepo-1.9.6-2.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-07c3e09858
Proposed as a Blocker for 30-final by Fedora user churchyard using the blocker tracking app because: "The installed system must be able appropriately to install, remove, and update software with the default console tool for the relevant software type (e.g. default console package manager). This includes downloading of packages to be installed/updated."
librepo-1.9.6-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-daf980b401
Guys, thanks so much for pushing this through. For full testing, you'll want to point one of the repositories to rawhide which has zchunk metadata.
librepo-1.9.6-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-07c3e09858
librepo-1.9.6-2.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-daf980b401
librepo-1.9.6-2.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
librepo-1.9.6-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1695616 has been marked as a duplicate of this bug. ***
We are getting a segmentation fault each time we run dnf. Core is not dumped. Version is dnf-0:4.2.11-2.fc30.noarch Running it a second time after updates are completed closes dnf normally. Initial run closes with: Completion plugin: Generating completion cache... Segmentation fault Second run: Completion plugin: Generating completion cache... --> Starting dependency resolution --> Finished dependency resolution Dependencies resolved. Nothing to do. Complete!
(In reply to SP from comment #21) > We are getting a segmentation fault each time we run dnf. Core is not > dumped. Version is dnf-0:4.2.11-2.fc30.noarch > Running it a second time after updates are completed closes dnf normally. > Initial run closes with: > > Completion plugin: Generating completion cache... > Segmentation fault Given where your error is occurring, it is unrelated to this particular bug report. You should open a new bug with detailed logs.