Bug 371111

I had the same experience, not with the DVD but with an NFS install of the
(supposedly) same tree. After waiting for about 2 hours I gave up ;-).

As a workaround, I downloaded the Everything tree and copied over this
files/dirs from the Fedora to the Everything tree:

.treeinfo
images
isolinux
media.repo

Then I used the resulting combined tree as installation source.

From that I gather that anaconda has serious problems with upgrading systems
that have (lots of?) packages that aren't contained in the default media.
Perhaps anaconda should offer to add additional repos so the additional packages
can be upgraded as well and don't ruin the dependency solving step.

I experience the same problem when attempting to upgrade from FC7 -> FC8. The
only differences compared to the original poster is that I'm using 
1. an i386 DVD and not the x86_64 DVD
2. regular hard disk partitions and not LVM

The problem occurs regardless of whether I use the GUI or text mode option for
the upgrade and it freezes at about 25% of the "Checking dependencies in
packages selected for installation...".

I'd be glad if someone could suggest a fix for this problem (that is less
painful than #1) to help me get through with this upgrade.

(And, yes, as #1 mentioned, I do have quite a number of packages that are not on
the default media or the fedora everything repo).

My hardware:
Asus A8V-Deluxe motherboard (VIA KT800 chipset), Athlon X2 4200+ processor,
Sapphire Radeon X1950Pro graphics card, 2 GB Transcend DDR2 RAM, PS2 keyboard,
USB mouse, Seagate 160GB SATA hard disk connected to an inbuilt Promise PDC20378
(FastTrak 378/SATA 378) controller.

I'm seeing the same problem when upgrading from F7 to F8, using the x86_64 DVD.
 I've tried installing twice, and both times it's hung at 26%.  An strace of the
anaconda process is pretty much the same as the one attached to bug #366641, and
it's using 100% of 1 CPU.

I definitely have some packages installed that aren't on the default install
DVD, but I don't think it's a huge number (and can't figure out how to list
installed RPMs by repository).

Same problem also for me.
FC8 i368 DVD:
- try to upgrade from fc7 on dell D620 (/dev/VolGroup/LogVol00) and anaconda
stops on 26% of "Checking dependencies..."

Got the same problem.  
Checked with yum list extras.  Seems it's only packages where the yum upgrade
failed during the year, I'm upgrading from FC6. I removed those packages and see
what happens. 

Ditto DVD upgrade on i386. I did upgrade one box successfully, so the package
combo must be causing this.

Indeed the problem was related to some packages for which the dependencies could
not be solved. Unfortunately, anaconda goes into an endless loop (yum does too
on attempt to yum update the OS) instead of just reporting that things won't
work out.

(In reply to comment #7)
> Unfortunately, anaconda goes into an endless loop (yum does too
> on attempt to yum update the OS) instead of just reporting that things won't
> work out.

Anaconda shouldn't just report that things don't work out (if they don't work
out), it should also offer to add external repositories just like when
installing (ideally it would come with "fedora" and "fedora-updates"
pre-configured). That way most packages should already be up to date when
booting into the upgraded system.

I've updated my fedora 7 before upgrade to fedora 8, but nothing has changed.
Anaconda stops always at the same point...
Please fix it or suggest a workaround!!!!!!

Can you try the update image at
http://katzj.fedorapeople.org/updates-f8-yumloop.img and see if it resolves the
problem?

The use of update images is described at
http://fedoraproject.org/wiki/Anaconda/Updates

I removed all packages reported by yum list extras. Same problem. Just hangs.

from http://fedoraproject.org/wiki/Anaconda/Updates I read:
...updates.img files provided by the Fedora project are gzip compressed cpio
archives"
But if I try to gunzip updates-f8-yumloop.img (renamed with extension .gz) I get
"not in gzip format".
So, putting it in a usb key, Anaconda stops just after dvd media test dialog.
Is file updates-f8-yumloop.img correct?

Regarding comment #8 - sure - but if there is no salvaging, it should not be
stuck in the endless loop, is what I meant.

Back to figuring out why hibernate causes SATA/ext3 to go berserk...

(In reply to comment #10)
> Can you try the update image at
> http://katzj.fedorapeople.org/updates-f8-yumloop.img and see if it resolves the
> problem?
> 
> The use of update images is described at
> http://fedoraproject.org/wiki/Anaconda/Updates

Nothing changed with the update image.
I've repeated all the procedure (...and changed usb key from last try!) but the
behavior is always the same: anaconda loads updates from the pendrive but stops
at the same point of the "Checking dependencies in packages selected for
installation...".

I have this problem too, exactly as described.
I have created a list of the packages I have installed and a sysreport, if this
can be helpfull to anyone.

Created attachment 253921 [details]
yum loop

Pointing yum to the F8 DVD as a repository, disabling all other repositories,
and running "yum update" yields the attached loop.

I'll try uninstalling the third-party packages listed there to see if I can
pinpoint the culprit...

after searching different list i found the following solution works for me:
remove these packages:
java
jdk
libvirt
gtk-vnc
xen
duplicate openoffice packages (just no recoginzed after rpm -qa|grep openof|sort)
compiz
glib-devel
NetworkManager
dbus
expat
avahi
those pacakges which has not contains the above names don't need to remove it
remove these with 
rpm -e --nodeps

Having the same problem here...

For me it worked doing a "yum -y remove NetworkManager" prior to the upgrade. I
had previously tried to remove 3rd-party packages as much as possible, with no
luck. It seems, from the different things people have to remove to work around
this issue, to be largely dependent on the packages installed. Isn't there a way
to make anaconda more verbose so we can catch these loops etc. in anaconda
itself, rather than having to setup mediarepos and running yum from an installed
system? That might be useful for this, and future anaconda problems!?

+1 on anaconda verbosity, though that only helps for people willing to do manual
package removals & re-installations.  In my case, after resolving the dependency
loop (which I'll blame a third-party package for), I ran into a long list of
failed dependencies.

I ended up forcibly removing a number of packages, both official Fedora ones and
3rd-party ones, to get rid of conflicts.  The biggest culprits seemed to be:

devel packages , as I suppose they aren't on the DVD but are tied to a
particular version of a package and thus hold back upgrades.

multi-lib problems: if you have both the i386 and x86_64 versions of a package
installed, sometimes the installed i386 will conflict with an update attempt on
the x86_64 version (I'm guessing when an updated x86_64 version is available
without a corresponding i386 update)

I saw this on two boxes had to delete wireless-tools-devel, avahi-compact-howl,
ImageMagick and  expat to get it working

According to some, the problem occurs even when attempting to upgrade with yum 
(without anaconda). yum goes to an infinite loop resolving dependencies:
https://www.redhat.com/archives/fedora-devel-list/2007-November/msg00562.html
I saw very similar reports here (in Czech, sorry):
http://www.abclinuxu.cz/blog/publish/2007/11/9/199508

Should this bug be reassigned to yum?

Created attachment 254301 [details]
verbose yum output

Yes it is a yum bug. I have attached the output of yum using only the dvd as
repo.
I cannot do any other tests because after deleting the packages I mentioned
above, I was able to update. (also saw this issue on 2 F7 boxes, but FC6->F8
worked just fine)

After resolving the yum loop, I tried another Anaconda upgrade, and it still
hung at 26%.  Running a yum update against the DVD, it listed a number of
missing dependencies (but no loop) - so at the very least, at that point
Anaconda should tell me there is a problem, rather than hanging.

*** This bug has been marked as a duplicate of 372011 ***

cd-record is one of the culprits, I think. It probably has something to do with
the package being dropped from distros due to the licensing issue. 

I think that if the anaconda installer just displayed the name of the package it
was looking for dependencies for, it would cut down the strife users are
experiencing greatly, as they could just remove the one troublesome package and
continue. I had to rpm -e over 600 packages before it worked :/