Bug 345701

Created attachment 234321 [details]
The dump from the upgrade.

Are you trying to upgrade an i386 system with x86_64, or vice-versa? 

No.  The upgrade is F-7-x86_64-DVD.iso and they are all 64bit Penguins and the
DVDs all pass the media check.

on your running FC5 system could you run: 

uname -a
rpm -q kernel
and cat /etc/rpm/platform

thanks

*** Bug 335521 has been marked as a duplicate of this bug. ***

I find it interesting that this bug is marked as a duplicate of mine.   I can't
find anything similar with the exception of the general task being attempted,
and the general title.   

The exact upgrade is different, as all of mine was with i386 and this is with
the 64 bit stuff.

I used an over the network upgrade and this is using dvds.

The results are also different.   This is getting a hang if I understand this
right and I got first an error exit, and then a trashed system.

If these are in fact the same bug, the reasons might be a great help to both of
us in solving the problem.

You are both getting the message "PackageSackError: No Package Matching
kernel.<arch>".  Although the end result (hang vs. error message) and arch are
different, the underlying causes are most likely going to be the same.

OK Interesting.   So I guess the question is where do we go from here.   I have
ended up doing a scratch install on the machine I was having problems with.   SO
it is presently running fc7.   One thing that might be a hint is that I did have
a problem with the fc5 install where the x server would not start up and I had
to do a text install.   But that seemed to run ok.

The question I have is why isn't there a option to just ignore and install?

Well I can think of one reason that you don't ignore.   If you ignore a missing
kernel package and therefore it doesn't install chances are you won't get a
bootable system.  I already have a couple of other bugs active regarding the
system installing an upgrade and then leaving you with an unbootable system.  
That is seriously not cool.   It is really annoying to then have to go in with a
rescue disk and copy all of the data off, and then reformat and fresh install,
and then copy the data back.

I'm not suggesting ignoring the missing kernel package, but rather for Kernel
packages only, force install.

As I understand the message I was getting, and as I understand it you were
getting, the system couldn't find a kernel package to install that it thought
even remotely related to the system it was being installed on.   Forcing an
install anyway would seem to me to be a great way to end up with a nonbootable
system.

Without a force option, the system is useless, so your point of "nonbootable" is
mute.

But as long as the system is bootable you can bring it back up and use it.   If
it is unbootable then you have a problem.   In my case (which this has been a
while ago), I just copied the information off the server to another server, did
a scratch install, and then copied the data back.  If I had used a force option
and created a nonbootable system this would have taken MUCH LONGER and been much
more difficult.

That's great for one system, when you have dozens of systems with installed
services/applications with individual setups, that is not a solution.

The bootable bit is the kernel.  Right now, the script halts with no option to
proceed.  You don't even get to see what it is looking for so you might be able
to install that bit.

So, the current situation is unacceptable.  

Actually I do have a few dozen systems.   That is why I hate the "force" option
idea.   I agree that this current situation is unacceptable.  But from what I
can tell the force option would simply leave you with a system that to even get
the data off of you would have to gen a new system on an extra box, and then
pull the drives and mount these drives in the new system and copy the data to
another system.   Then you wold have to mount them back in the orginal box and
do a scratch install, and then copy down the data.   

As someone with multiple systems to upgrade this would really impress me as a
true nightmare.

As a possible solution, I have been using backuppc.   I am extraordinarily happy
with the results.   I recently had to recover from a multiple drive failure on a
raid array.   (don't ask you don't want to know how this happened. ;-)  )   This
server had seven different very complex web sites with multiple ips and services
for all of them, all with separate configurations.  It also had several other
services running on it.  Now I had a bood backuppc copy of the system.   It took
longer to fix the hardware and gen a new OS than it did to restore the services
and get everything back up and running.   If I had to do this copy off, gen, and
copy back thing ever again; that is how I would do it.

Are you still having this problem?

If so maybe we can figure out where the problem is at?

I don't see much movement here.   One possible solution to try is fc9 beta.   I
have been running this on one of my non production/production servers with no
major problems.   At this point fc7 is enough behind the curve I would worry
about running it.   If I had to run the fc9 beta to get back up I would not have
a real concern about it.   It already is more stable than a production service
pack 1 version of a microsoft product.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Have you run into the same problem when upgrading to F9?

Don't have this problem with FC9.   In fact the solution was that I switched
this machines to fc9 beta.   I also basically did a scratch install and then
reloaded the configs.

Don't have any machines experiencing this particular problem any more

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.