Bug 186541

Description of problem:

I wanted to upgrade my system from fc4 to fc5.

I used pxeboot and then the http install to upgrade the system.
After some time it showed the message:
    Preparing transaction from installation source...

Al that time it was doing lots of io. Probably the io was
the cause of the slow upgrade,

After 9 hours the progress bar was at 75%.
At that moment i stopped the upgrade.

The system is a 2 Ghz laptop with a 4200 rpm 2.5 inch laptop disk
and 512 mb memory.

How reproducible:


Steps to Reproduce:
1. Use a laptop with comparable specs
2. Install fc4 with lots of packages including extra packages
3. Boot the fc5 pxe upgrade images with pxe
4. Choose to upgrade
5. Wait

  
Actual results:
  I waited 9 hours. After that i reboted because i wanted to use my laptop
  and not to wait for a upgrade.

Expected results:
  The system should be upgradable in a window of 2 hours.

Network install is a process that largely depends on your environnement : which
mirror you are using, its bandwitch, ISP's bandwitch, etc. Maybe a small
enhancement of Anaconda would be useful, but well, anaconda isn't really
accountable for this slowness IMHO.

I think this isn't a bug.

It never started to install!

It was in the stage "Preparing transaction from installation source..."
and anaconda was doing a lot of local io on the harddisk.

Besides that the webserver serving the files was a private webserver
on a local 100 Mbit lan.

Created attachment 126706 [details]
Some logfiles and output of commands (e.g. top) during the install

Log files from "/tmp":
	anaconda.log
	yum.conf
	lvmout
	syslog
	X.log

Output of commando's:
	File		Command
	------------	----------------------------
	top.txt 	/mnt/sysimage/usr/bin/top -b
	lsof.txt	lsof
	lsof_p571.txt	lsof -p 571
	vmstat_5.txt	vmstat 5
	free.txt	free

I repeated the exercise and checked the system after a few hours running.

At that time top showed:
------------------------
top - 10:56:33 up  9:17,  0 users,  load average: 1.71, 1.55, 1.45
Tasks:  43 total,   1 running,  42 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.6% us,  1.5% sy,  0.0% ni,  0.4% id, 92.1% wa,  0.3% hi,  0.0% si
Mem:    515888k total,   510076k used,     5812k free,    20140k buffers
Swap:  1048568k total,   580008k used,   468560k free,   145076k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  571 root      18   0 1136m 253m 1680 D  2.0 50.3  37:16.33 anaconda


So it really looks like anaconda is trashing the system.

Does an nfs upgrade work any quicker?

I too tried to upgrade from Fedora Core 4 to Fedora Core 5 by FTP.  After an
hour the progress bar reached under the 'n' in "installation" and did very
little for eleven hours.   After which, there was an error saying my computer
had insufficient storage and exited.  The upgrade.log & upgrade.log.syslog file
in /root were of zero length.  the utility "df" reports:

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda5             2.4G  1.1G  1.2G  46% /
/dev/hdb1             4.7G  3.3G  1.3G  73% /opt
/dev/hdb2             4.7G  4.0G  554M  88% /home
/dev/hdb3             4.7G  3.2G  1.3G  72% /usr
/dev/hdb4             4.8G  3.0G  1.6G  66% /var
none                  157M     0  157M   0% /dev/shm

and, the swap files are:

144585   82  Linux swap
and,
-rwxr-xr-x   1 root    root    523239424 May 22  2002 SWAP

I was also wondering why it took so long to fail (12 hours)
and why the upgrade logs were empty.

Nfs has the same problem.

You win 80 mb because the stage2.img isn't copied to the tmpfs disk.

But it doesn't solve the problem that anaconda is using more then 1 GB of
memory.

As far as i can see anaconda is doing a cross check between the rpm database
"/var/lib/rpm" and the files on disk.

I found a workarround to upgrade.

After checking anaconda with strace i found that it did lots of stats on
"/usr/src/kernels/*". After some time it would check some other files and
after that i found that it was again checking files in the kernel source
tree.

So i removed the following redhat kernel source packages:
        kernel-xen0-devel-2.6.12-1.1447_FC4
        kernel-devel-2.6.14-1.1656_FC4
        kernel-xenU-devel-2.6.12-1.1447_FC4
        kernel-xenU-devel-2.6.13-1.1526_FC4
        kernel-devel-2.6.15-1.1833_FC4
        kernel-devel-2.6.11-1.1369_FC4
        kernel-xen0-devel-2.6.13-1.1532_FC4
        kernel-xen0-devel-2.6.12-1.1398_FC4
        kernel-devel-2.6.14-1.1637_FC4
        kernel-devel-2.6.12-1.1447_FC4
        kernel-devel-2.6.13-1.1532_FC4
        kernel-xen0-devel-2.6.12-1.1456_FC4
        kernel-devel-2.6.14-1.1644_FC4
        kernel-xenU-devel-2.6.12-1.1398_FC4
        kernel-devel-2.6.12-1.1456_FC4
        kernel-devel-2.6.12-1.1398_FC4
        kernel-xenU-devel-2.6.12-1.1456_FC4
        kernel-devel-2.6.14-1.1653_FC4
        kernel-devel-2.6.15-1.1830_FC4
        kernel-xenU-devel-2.6.13-1.1532_FC4
        kernel-devel-2.6.13-1.1526_FC4
        kernel-xen0-devel-2.6.13-1.1526_FC4
        kernel-devel-2.6.15-1.1831_FC4

After that the upgrade finnisched in 2.5 hours without swapping.

(In reply to comment #9)
> I found a workarround to upgrade.
> 
> After checking anaconda with strace i found that it did lots of stats on
> "/usr/src/kernels/*". After some time it would check some other files and
> after that i found that it was again checking files in the kernel source
> tree.
> 
> So i removed the following redhat kernel source packages:
>         kernel-xen0-devel-2.6.12-1.1447_FC4
>         kernel-devel-2.6.14-1.1656_FC4
>         kernel-xenU-devel-2.6.12-1.1447_FC4
>         kernel-xenU-devel-2.6.13-1.1526_FC4
>         kernel-devel-2.6.15-1.1833_FC4
>         kernel-devel-2.6.11-1.1369_FC4
>         kernel-xen0-devel-2.6.13-1.1532_FC4
>         kernel-xen0-devel-2.6.12-1.1398_FC4
>         kernel-devel-2.6.14-1.1637_FC4
>         kernel-devel-2.6.12-1.1447_FC4
>         kernel-devel-2.6.13-1.1532_FC4
>         kernel-xen0-devel-2.6.12-1.1456_FC4
>         kernel-devel-2.6.14-1.1644_FC4
>         kernel-xenU-devel-2.6.12-1.1398_FC4
>         kernel-devel-2.6.12-1.1456_FC4
>         kernel-devel-2.6.12-1.1398_FC4
>         kernel-xenU-devel-2.6.12-1.1456_FC4
>         kernel-devel-2.6.14-1.1653_FC4
>         kernel-devel-2.6.15-1.1830_FC4
>         kernel-xenU-devel-2.6.13-1.1532_FC4
>         kernel-devel-2.6.13-1.1526_FC4
>         kernel-xen0-devel-2.6.13-1.1526_FC4
>         kernel-devel-2.6.15-1.1831_FC4
> 
> After that the upgrade finnisched in 2.5 hours without swapping

Do you mean all kernel source in the /usr/src/kernels directory?

I did a "rpm -e" on all those packages.

After that there where stil a few object files there in one of the trees so i
did a "rm -rf" to compleetly wipe it.

So "/usr/src/kernels" was clean before i started the upgrade.

I did nearly the same thing, except I didn't do the "rpm -e" bit and I still got
the insufficient disk space.  Could it be I'm running out of swap space.  I have
over 600 MB worth.  Any ideas, maybe add to the swap space?

> I did nearly the same thing, except I didn't do the "rpm -e" bit and I still
> got the insufficient disk space.

In that case you did something completly different.

The "rpm -e" also removes the administration in "/var/lib/rpm".
After that i did a rebuild of the rpm database and the basename file
changed from 10 MB to 5 MB.

> Could it be I'm running out of swap space.  I have over 600 MB worth.

I don't think so. My system has 512 MB of ram and didn't use any swap
during the upgrade. So 512 MB should be enough.

> Any ideas, maybe add to the swap space?

Yes. Cleanup your rpm database.

I remove approximatly 30 packages from my RPM database and tried again to do a
FTP upgrade.  This time I failed only after 4 hours.  It would be nice to know
how much disk space is needed in which filesystems (see above in comment #7). 
I'm going to keep removing unnecessary RPM packages until I the upgrade actually
starts.

I removed even more RPM package and successfully upgraded to FC5.  A little
history about my system, I've been upgrading since RedHat 5.0 over the network.
 Since I did not clean up my RPM package, assuming it was done during each
upgrade, my RPM database was becoming bloated to the point when I first tried to
upgrade to FC5, I was told that I did not have enough disk space.  By using "rpm
-e" to remove old and unnecessary packages, I was able to free up enough disk
space to be able to successfully upgrade to FC5.

The moral of the story is:

Before each upgrade,

rpm -e "<old-or-unnecessary-RPMS>"
rpm --rebuilddb
Do the network upgrade

I'm also getting the 'error running transaction' because of 'insufficient disk
space' during an upgrade from local DVD media. 

It appears to be /usr that's complaining about. This filesystem is 6.5GB in size
and currently has 1.8GB free. Is it possible the required additional space for
the upgrade is being calculated incorrectly? I've already tried rebuilding the
rpm database and that wasn't the issue.

This error message is very frustrating as it provides no information on what the
underlying problem is or how to solve it. It would be good if it could be
improved and even better if the need to restart the install from scratch could
be avoided.

Before you rebuild the RPM database, you must remove any old or unnecessary RPM
packages on your system.  Use a GUI frontend for RPM to find which out of date
and unused RPM packages you can removed.  Examples are the HOWTOs in foreign
languages (i.e. not your home language), games, unused computer languages or
programs.

From your comment, /usr with only 1.8 GB free may not be enough.  Send the
output of the disk usage utility, "df".  It will tell you the current disk usage
for all of your file systems.

Please re-read comment #15 above.

User pnasrat's account has been closed

Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?

I haven't noticed it any more.

But i clean my systems before upgrading and use the yum upgrade path.
So that isn't a representative test.