I've had this problem (or a similar problem like this for 2 or three releases now, can't remember when preupgrade was disabled if /boot is on raid, was that F15 or F16?)
Since my /boot is RAIDed I can't use preupgrade which is smart enough to download all the packages. Instead I use the DVD and the anaconda installer to do my updates. i ALWAYS run into problems with dependencies when this happens.
So as usual, a ton of my packages didn't get updated because the installer DVD doesn't seem able to pull packages over the network.
After upgrade, I boot into a semi-working system and do a yum update and get about 700 packages that have to be upgraded. Guess what, this fails, because a number of the .i686 packages now have new dependencies at F17. But i can't just install the dependencies I need because in some cases, the .x86_64 versions installed are too old and I get the protected multilib error.
So I have to
a) find all the dependencies that are missing from the extremely cryptic yum update error messages
b) attempt to manually install the dependencies.
c) if the dependencies fail to install, for example if the x86_64 versoin are older than the version being pulled from the current repo, I have to fix that problem.
rinse and repeat. what is normally a MUCH MUCH smoother process with preupgrade seems to be alot uglier when it comes to anaconda installs.
i'd much rather have preupgrade running with /boot on RAID and have to manually fix grub (which I believe is the primary reason why preupgrade is disabled for /boot on RAID, because of grub booting problems) than fix the annoying dependencies issues that occur. Either that or the anaconda upgrade needs to be smart enough to download packages online.
Really though it boils down to pretty much a lack of support for /boot on RAID with preupgrade. If that works, or even if it succeeds with a non-bootable system afterwards, it takes a lot less time to fix grub than it does to fix stupid rpm dependencies
Threaded Mode
