Bug 538748
| Summary: | Failure in yum-complete-transaction, due to disk space errors (which seem wrong) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Zdenek Kabelac <zkabelac> |
| Component: | yum-utils | Assignee: | Seth Vidal <skvidal> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | ffesti, james.antill, jnovy, maxamillion, n3npq, pmatilai, tim.lauridsen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | yum-utils-1.1.27-2.fc13 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-14 17:21:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
y-c-t should probably catch this error, and just print it not traceback. But the real error here seems to be from rpm. Can you provide a full "df -h"? Also what does "yum --version" say? I assume at this moment it was this version: Oct 19 10:14:55 Updated: yum-3.2.25-1.fc12.noarch Because I've not left my machine in such broken state and finished all the installation properly by hand. Thus now I have this info: 3.2.25 Installed: rpm-4.7.1-9.fc13.x86_64 at 2009-11-16 14:50 Built : Fedora Project at 2009-11-16 14:39 Committed: Jindrich Novy <jnovy> at 2009-11-16 12:00 Installed: yum-3.2.25-1.fc13.noarch at 2009-11-19 10:53 Built : Fedora Project at 2009-10-14 20:06 Committed: Seth Vidal <skvidal at fedoraproject.org> at 2009-10-14 12:00 #df -h /dev/sda5 8,7G 7,7G 569M 94% / tmpfs 1,9G 532K 1,9G 1% /dev/shm /dev/sda1 190M 71M 110M 40% /boot /dev/sda7 56G 53G 424M 100% /home Yes - there is not a lot of free space ;) But I've been able manually to finish all transactions and upgrades. We meet again ;) Yes, the message is awkward. There's a missing "additional" in the message that (at least to this en_US speaker who wrote the text) is implied by "need". The really hard problem is how to translate "need", which is quite subtle, to other languages. The other flaw is that ENOSPC messages cascade to stderr, with increasing needed space needs as a transaction proceeds, with the message attached to packages, rather than mount points, all of which is hopelessly confusing. Also unfortunate is that this (and the other ~17 messages from RPM) are constrained to a certain template from; there have been installers with *RE's scraping information directly from the error message text. And using a rpmProblemSet doesn't really help because the overloading in the fields to carry as much info as possible doesn't work very well. Like Jeff pointed out, what the disk space message is *really* saying is "to complete, this transaction needs 2MB more free space than is available on / filesystem". Without the full details of the transaction in question it's impossible to say whether it actually required over 560MB free space on /, but it's certainly possible with an update involving ~1400 packages. So short of the unclear message, I dont see any obvious rpm bug here... Back to yum-utils which should catch the exception instead of blowing up. Well yes - rpm itself was not able to make the full -Uvh on downloaded packages - but the message from is much better readable. This bugzilla is not about rpm - but about misleading mesages from yum utils. IMHO yum user is put into the situation which he cannot resolve unless he is quite experienced linux user.... The fact that rpm itself cannot select packages into transaction so they fit available free space is another set of problems. But I assume it's mainly issue for kvm users with limited disk sizes for their vm - thus probably not an issue for average >100GB disk users. This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Added exception capture upstream. http://yum.baseurl.org/gitweb?p=yum-utils.git;a=commitdiff;h=a7c6d28d68703c0958a5e7a4ac49b637235d54de yum-utils-1.1.27-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/yum-utils-1.1.27-1.fc13 yum-utils-1.1.27-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update yum-utils'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/yum-utils-1.1.27-2.fc13 yum-utils-1.1.27-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: While tryint to upgrade my rawhide today - I needed to run yum-complete-transaction - but it fails with this traceback: Traceback (most recent call last): File "/usr/sbin/yum-complete-transaction", line 211, in <module> util = YumCompleteTransaction() File "/usr/sbin/yum-complete-transaction", line 118, in __init__ self.main() File "/usr/sbin/yum-complete-transaction", line 196, in main if self.doTransaction() == 0: File "/usr/share/yum-cli/cli.py", line 490, in doTransaction resultobject = self.runTransaction(cb=cb) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1090, in runTransaction raise Errors.YumBaseError, errors yum.Errors.YumBaseError: [('installing package kdevelop-libs-9:3.9.95-0.1.beta5.fc13.x86_64 needs 2MB on the / filesystem', (9, '/', 1478656L))] # LANG=C df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda5 9068616 8049360 558596 94% / So there is 560MB free space. Also the message itself is a bit awkward... Version-Release number of selected component (if applicable): yum-utils-1.1.23-3.fc12.noarch And the CPU time to process those 1400 entries... but this is for another bugzilla I guess.. How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: