This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 186541 - Upgrade from fc4 to fc5 takes to long
Upgrade from fc4 to fc5 takes to long
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
5
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Peter Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-24 03:36 EST by Marcel Nijenhof
Modified: 2008-03-11 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-11 11:37:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A list of installed packages (7.89 KB, application/x-bzip2)
2006-03-24 03:36 EST, Marcel Nijenhof
no flags Details
Some logfiles and output of commands (e.g. top) during the install (23.39 KB, application/x-bzip2)
2006-03-25 05:36 EST, Marcel Nijenhof
no flags Details

  None (edit)
Description Marcel Nijenhof 2006-03-24 03:36:22 EST
Created attachment 126610 [details]
A list of installed packages
Comment 1 Marcel Nijenhof 2006-03-24 03:36:22 EST
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.
Comment 2 François Obada 2006-03-24 05:48:41 EST
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.
Comment 3 Marcel Nijenhof 2006-03-24 05:56:52 EST
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.
Comment 4 Marcel Nijenhof 2006-03-25 05:36:14 EST
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
Comment 5 Marcel Nijenhof 2006-03-25 05:40:32 EST
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.
Comment 6 Paul Nasrat 2006-03-27 14:20:03 EST
Does an nfs upgrade work any quicker?
Comment 7 John E. Harbold 2006-03-27 21:51:44 EST
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.
Comment 8 Marcel Nijenhof 2006-03-28 05:16:00 EST
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.
Comment 9 Marcel Nijenhof 2006-03-28 09:37:22 EST
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.
Comment 10 John E. Harbold 2006-03-28 21:23:47 EST
(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?
Comment 11 Marcel Nijenhof 2006-03-29 16:52:42 EST
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.
Comment 12 John E. Harbold 2006-03-30 08:53:35 EST
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?
Comment 13 Marcel Nijenhof 2006-03-30 14:36:55 EST
> 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.

Comment 14 John E. Harbold 2006-03-31 09:18:56 EST
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.
Comment 15 John E. Harbold 2006-04-02 21:32:52 EDT
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
Comment 16 Martin Smith 2006-04-07 07:42:47 EDT
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.
Comment 17 John E. Harbold 2006-04-07 09:25:46 EDT
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.
Comment 18 Red Hat Bugzilla 2007-08-21 01:23:02 EDT
User pnasrat@redhat.com's account has been closed
Comment 19 petrosyan 2008-03-11 00:49:06 EDT
Fedora Core 5 is no longer maintained. Is this bug still present in Fedora 7 or
Fedora 8?
Comment 20 Marcel Nijenhof 2008-03-11 05:52:01 EDT
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.

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