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: 100% 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)
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.