Bug 1005895
Summary: | Upgrade to f20 fails because of deltarpms | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Owen Taylor <otaylor> | ||||
Component: | fedup | Assignee: | Will Woods <wwoods> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 19 | CC: | awilliam, bloch, brunojcm, collura, kparal, matteo, mruckman, robatino, tflink, wwoods | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | RejectedBlocker | ||||||
Fixed In Version: | fedup-0.8.0-3.fc19 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-12-19 07:22:36 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Owen Taylor
2013-09-09 15:46:23 UTC
Adding deltarpm=0 to /etc/yum.conf worked around the problem This commit should fix it: https://github.com/wgwoods/fedup/commit/625f69f If someone could apply it (by hand if needed - it's a simple one-line fix) and verify that it fixes the problem that would be mighty helpful. Thanks Will, I just tried adding that line to download.py, and indeed it fixes the problem. As this breaks upgrades with the default configuration and the workaround isn't obvious, it's a major issue. Proposing as a blocker, criterion https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Upgrade_requirements : "For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed." Discussed this in 2013-10-21 Blocker Review Meeting [1]. It was agreed to punt as it is not clear whether this is actually a dupe of kparal's [2] and only affects fedup runs with --instrepo, we will discuss this again at the next meeting after kparal has evaluated it [1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-21/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1017205 *** Bug 1017205 has been marked as a duplicate of this bug. *** It seems that this problem does not occur if you don't use --instrepo (it seems that deltarpms are downloaded only from instrepo, not from main repos, for whatever reason). Discussed at 2013-10-23 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-23/f20-blocker-review.2013-10-23-16.00.log.txt . Rejected as a blocker: it now seems clear this doesn't happen unless --instrepo is passed. --instrepo will usually be passed only in special situations and by QA testers before release, not in 'typical' post-release use. Just got a similar problem right now, fedup 0.7.3-4.fc19: [root@brunojcm-fedora ~]# fedup --network 20 --instrepo http://dl.fedoraproject.org/pub/fedora/linux/development/20/x86_64/os/ setting up repos... getting boot images... .treeinfo | 1.1 kB 00:00:00 setting up update... finding updates 100% [======================================================================================================================] verify local files 100% [===================================================================================================================] pyliblzma-0.5.3-10.fc20.x86_64.rpm | 46 kB 00:00:00 Downloading failed: Errors were encountered while downloading packages. pyliblzma-0.5.3-10.fc20.x86_64: failure: Packages/p/pyliblzma-0.5.3-10.fc20.x86_64.rpm from cmdline-instrepo: [Errno -1] Package does not match intended download. Suggestion: run yum --enablerepo=cmdline-instrepo clean metadata Your log doesn't mention anything about drpms. This is a totally different problem. This is likely exactly what it says - the file on the server doesn't match the yum metadata. Try 'fedup --clean-metadata' to clear the metadata. I think it's the same problem, because the patch fixed the problem for me. After put 'conf.deltarpm = 0' in the download.py, no more errors during download phase. After fixing this bug, I'm back to my original issue: https://bugzilla.redhat.com/show_bug.cgi?id=1038863 fedup-0.8.0-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/fedup-0.8.0-3.fc19 fedup-0.8.0-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedup-0.8.0-3.fc20 fedup-0.8.0-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/fedup-0.8.0-3.fc18 Package fedup-0.8.0-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing fedup-0.8.0-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-23316/fedup-0.8.0-3.fc19 then log in and leave karma (feedback). fedup-0.8.0-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. fedup-0.8.0-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. fedup-0.8.0-3.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |