Bug 810289
Summary: | Anaconda should check space on upgrade | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matthias Runge <mrunge> | ||||
Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 17 | CC: | anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, robatino, vanmeeuwen+fedora | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | RejectedBlocker | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-01-20 17:40:09 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
Matthias Runge
2012-04-05 14:29:00 UTC
Questionable, how much damage is made during upgrade attempt. This is a difficult problem to solve. At install time we check the install size that yum gives us against the target's size. That doesn't take into account %postin scripts doing things but is a fairly good estimate. During upgrades we have the same information, but we have no way to tell how that compares to the installed footprint or how much slop will be needed for unpacking, metadata, whatever else yum/rpm do in the background. We don't really want to set an absolute minimum free space for upgrades because that varies based on the installed packages. So, I'm really not sure how to solve this. Note that this is not a new problem, and usrmove actually does the right thing when it runs out of space, it will back out the changes and remove its backups. No matter when the upgrade fails the system will be left in an intermediate state. This bug was discussed at the 2012-04-05 go/no-go meeting - http://meetbot.fedoraproject.org/fedora-meeting-1/2012-04-05/gono-go_continuation_f17_beta_rc3_part_two_or_three.2012-04-05-15.00.html . We noted that, as Brian touched on above, this is not actually a new problem, it's not one that anaconda has ever really addressed, and it's not one that's particularly susceptible to being fixed. After kicking it around we agreed that usrmove doesn't actually change much: its own space requirement is minimal (around 50MB) and, although it's true that a system which has been /usr-moved cannot be used as an F16 system any more, this isn't really any worse than the past, because any time anaconda fails to upgrade due to lack of space the resulting system is likely to be unusable until the upgrade is completed somehow. As anaconda doesn't check for available space and then refuse to try and upgrade if it is insufficient, its 'failure mode' has _always_ been to try and do the upgrade and fail halfway through, which is always likely to render the system unusable as-is. Taking the above factors into account, we agreed this is not a blocker bug, though the result is certainly unfortunate. All we can suggest is that it be clearly documented that users should check for sufficient free space before upgrading. It is possible that anaconda could set an arbitrary 'low disk space' level - say 1GB - and warn if the available free space is less than this level, with the option to proceed if desired. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #2) > This is a difficult problem to solve. At install time we check the install size > that yum gives us against the target's size. That doesn't take into account > %postin scripts doing things but is a fairly good estimate. > Imho it would really help to do the check, if there's enough space on disk prior to any other upgrade action. Then we won't have a system in a partially migrated state, in my short thought, all information needed is already there. Hard coding a minimum free disk size would be a ugly solution, but would prevent such kind of failures also (although I wouldn't try to avoid this by any chance). If there's nothing like usr-move, one can try the update and the system won't be touched, if there's not enough free space on disk, so I see a regression here. I haven't never seen a partial upgraded system, because of run out of disk space before this. I must admit, this proposal won't solve all issues one may encounter for all possible migration/upgrade scripts run prior just package upgrade steps. With F18, we've moved to a simpler upgrade process that does not involve anaconda in the least. We're using a tool called fedup now that takes the place of preupgrade, and then uses regular system tools to do the upgrade itself. With anaconda no longer involved, this bug report should no longer be relevant. |