Bug 810289 - Anaconda should check space on upgrade
Summary: Anaconda should check space on upgrade
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 17
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker
Depends On:
TreeView+ depends on / blocked
Reported: 2012-04-05 14:29 UTC by Matthias Runge
Modified: 2013-01-20 17:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-01-20 17:40:09 UTC
Type: Bug

Attachments (Terms of Use)
dracut log (96.25 KB, application/octet-stream)
2012-04-05 14:29 UTC, Matthias Runge
no flags Details

Description Matthias Runge 2012-04-05 14:29:00 UTC
Created attachment 575448 [details]
dracut log

Description of problem:
during upgrade from f16 to f17, anaconda should do a check, if space is enough. If not enough space on disk, usr-move should not be executed. 

Version-Release number of selected component (if applicable):
all recent versions I tested, e.g. from f17 beta rc2, rc3

How reproducible:

Steps to Reproduce:
1. Install f16 on a vm, take e.g. 8 gig of disk space
2. get a recent beta rc from http://dl.fedoraproject.org/pub/alt/stage/17-Beta.RC3/Fedora/x86_64/iso/Fedora-17-Beta-x86_64-netinst.iso
3. take care on your virtual machine is about 700 megs of space free (not more)
4. boot your vm using the downloaded iso
5. usr-move is executed, anaconda will not upgrade your machine, bc. of missing space

(every output from machine after attempted upgrade):
[root@localhost ~]# df -h
Filesystem                    Size  Used Avail Use% Mounted on
rootfs                        5.6G  4.9G  431M  92% /
devtmpfs                      488M     0  488M   0% /dev
tmpfs                         499M   76K  499M   1% /dev/shm
/dev/mapper/VolGroup-lv_root  5.6G  4.9G  431M  92% /
tmpfs                         499M   49M  450M  10% /run
tmpfs                         499M     0  499M   0% /sys/fs/cgroup
tmpfs                         499M     0  499M   0% /media
/dev/vda2                     497M   49M  423M  11% /boot

[root@localhost ~]# cat /etc/fedora-release 
Fedora release 16 (Verne)

[root@localhost ~]# ls -l /
total 62
lrwxrwxrwx.   1 root root     7 Apr  5 08:05 bin -> usr/bin
dr-xr-xr-x.   5 root root  1024 Apr  4 11:23 boot
drwxr-xr-x.  18 root root  3300 Apr  5 08:42 dev
drwxr-xr-x. 123 root root 12288 Apr  5 09:17 etc
drwxr-xr-x.   3 root root  4096 Apr  4 13:13 home
lrwxrwxrwx.   1 root root     7 Apr  5 08:05 lib -> usr/lib
lrwxrwxrwx.   1 root root     9 Apr  5 08:05 lib64 -> usr/lib64
drwx------.   2 root root 16384 Apr  4 10:01 lost+found
drwxr-xr-x.   2 root root    40 Apr  5 08:42 media
drwxr-xr-x.   2 root root  4096 Jul 29  2011 mnt
drwxr-xr-x.   2 root root  4096 Jul 29  2011 opt
dr-xr-xr-x. 135 root root     0 Apr  5 10:42 proc
dr-xr-x---.   6 root root  4096 Apr  5 14:24 root
drwxr-xr-x.  29 root root  1080 Apr  5 08:43 run
lrwxrwxrwx.   1 root root     8 Apr  5 08:05 sbin -> usr/sbin
drwxr-xr-x.   2 root root  4096 Jul 29  2011 srv
drwxr-xr-x.  13 root root     0 Apr  5 10:42 sys
drwxrwxrwt.  15 root root  4096 Apr  5 10:56 tmp
drwxr-xr-x.  13 root root  4096 Apr  5 08:05 usr
drwxr-xr-x.  17 root root  4096 Apr  4 11:15 var

upgrade log:
[root@localhost ~]# cat upgrade.log
08:14:33 Upgrading filesystem-3-2.fc17.x86_64
warning: filesystem-3-2.fc17.x86_64: Header V3 RSA/SHA256 Signature, key ID 1aca3465: NOKEY

(rather short)

Comment 1 Matthias Runge 2012-04-05 14:37:59 UTC
Questionable, how much damage is made during upgrade attempt.

Comment 2 Brian Lane 2012-04-05 21:58:16 UTC
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.

Comment 3 Adam Williamson 2012-04-06 04:17:36 UTC
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

Comment 4 Matthias Runge 2012-04-07 15:53:38 UTC
(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.

Comment 5 Chris Lumens 2013-01-20 17:40:09 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.