Bug 193887

Can you switch to tty2 when this occurs and grab /tmp/anaconda.log and /tmp/syslog?

Created attachment 130459 [details]
/tmp/anaconda.log at time of failure

Created attachment 130460 [details]
/tmp/syslog at time of failure

Created attachment 130461 [details]
Output from df command at time of failure

OK, I've attached copies of the files you requested, including a copy of a 
"df" command executed in tty2.

I'll be interested to hear why 1.6GB of free space on /usr is insufficient :-)

rpmlib is definitely reporting that there's a need for more space.  Do you have
any symlinks that you manually created under /var or /usr that could be pointing
to an absolute path and confusing things?

I don't remember manually linking anything in either /var or /usr on this 
system. In fact, I rarely link files/directories.  In looking at /var, at the 
top level, the only link I see is "mail -> spool/mail" and in /usr "tmp 
-> ../var/tmp".  All my filesystems are either ext2 (/ and /boot) or ext3 and 
mounted normally, nothing fancy.

The values returned by "df" make perfect sense knowing my setup. I should have 
plenty of space on all partitions, and I have never had a partition fill.

Do you have a test program for rpmlib that I could run?

I did an "rpm --rebuilddb" and it made no difference.  Then just to ensure 
that the df numbers are correct I did copied a 1.2GB directory into /usr:

--- Before copy 
[root@rufus src]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              5044188   3031792   1756160  64% /
/dev/hda1               600832      7568    562744   2% /boot
/dev/hda3               719452     17140    665768   3% /cd
none                    515892         0    515892   0% /dev/shm
/dev/hda8             95871976  14178644  76823232  16% /home
/dev/hda6              5044156     43288   4744636   1% /tmp
/dev/hda5              6048320   4103184   1637896  72% /usr

--- Copy 1.2GB directory (see below for df of var)
[root@rufus src]# cp -a var /usr

--- df after copy, /usr is as expected
[root@rufus src]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              5044188   3031792   1756160  64% /
/dev/hda1               600832      7568    562744   2% /boot
/dev/hda3               719452     17140    665768   3% /cd
none                    515892         0    515892   0% /dev/shm
/dev/hda8             95871976  14235456  76766420  16% /home
/dev/hda6              5044156     43288   4744636   1% /tmp
/dev/hda5              6048320   5387592    353488  94% /usr

--- Size of var
[root@rufus src]# du -s var
1285420 var

--- remove big directory and we get back to what we had before
[root@rufus src]# rm -rf /usr/var
[root@rufus src]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda2              5044188   3031792   1756160  64% /
/dev/hda1               600832      7568    562744   2% /boot
/dev/hda3               719452     17140    665768   3% /cd
none                    515892         0    515892   0% /dev/shm
/dev/hda8             95871976  14202144  76799732  16% /home
/dev/hda6              5044156     43288   4744636   1% /tmp
/dev/hda5              6048320   4103184   1637896  72% /usr

There seems to be a bug somewhere the calculation of free space during the 
upgrade.

I have worked on this code some post-FC5 because that error message you're
getting is not at all helpful.  In future releases, it will tell you which
partitions are low on space, and how much additional free space is required.  I
guess that's not much help for you right now, but FC6test1 should do a better job.

I'm pleased to hear that you have improved the error message because I can 
imagine that some users may not have sufficient free space so knowing the 
partition and how much space is needed will be a big help.  

However, in my case, there seems to be a bug, and if I am interpreting the 
output from anaconda.log correctly, it looks like I am totally out of luck 
without a bug fix because no matter how I attempt to upgrade xorg-x11... I 
will have problems. That implies to me an install.

Is there any way I can upgrade -- even manually?

The problem appears to be due to the DVD iso, which I was using.  Note, I 
verified the sha1sum before burning the DVD and it matches exactly.

The reason I say this appears to be due to the DVD iso is because I just did 
an upgrade using the 5 CD set, and did not have the insufficient disk space 
problem.

The fourth disk was apparently bad or unreadable, which caused the upgrade to 
fail before it was complete.  I later fixed this using yumex to upgrade the 
remaining rpms.  However, it sure would be nice to have a dialog that permits 
retrying the CD if there is an error.  That would permit the user to burn a 
new CD and try again rather than have a total failure.  I seem to recall that 
this was the way FC4 installed (I had several bad CDs due to a CD 
manufacturing problem).

For me, the problem is solved, but there is something screwed up about either 
the DVD creation process or that particular DVD release.

requested by Jams Antill

As far as I am concerned, you can close this bug report. I no longer use 
Fedora.