This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 345701 - FC7 upgrade fails
FC7 upgrade fails
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
7
x86_64 Linux
low Severity urgent
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 335521 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-22 14:30 EDT by Peter
Modified: 2014-01-21 17:59 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:43:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
The dump from the upgrade. (111.94 KB, text/plain)
2007-10-22 14:30 EDT, Peter
no flags Details

  None (edit)
Description Peter 2007-10-22 14:30:57 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:  I have 6 identical systems.  On 2, there was no problem.  On
the other 4 the upgrade doesn't get past the "checking dependencies"


Steps to Reproduce:
1. Boot to DVD
2. Select install or upgrade GUI
3. Indicate upgrade and work through with the defaults till it starts to check
the dependencies.

  
Actual results:
Upgrade never completes.

Expected results:
Complete upgrade.

Additional info:
The DVD passes the media check.  I can't do a fresh install due to the size of
the data.
The upgrade is from FC5 to FC7.
Comment 1 Peter 2007-10-22 14:30:57 EDT
Created attachment 234321 [details]
The dump from the upgrade.
Comment 2 Will Woods 2007-10-22 14:48:55 EDT
Are you trying to upgrade an i386 system with x86_64, or vice-versa? 
Comment 3 Peter 2007-10-26 07:21:23 EDT
No.  The upgrade is F-7-x86_64-DVD.iso and they are all 64bit Penguins and the
DVDs all pass the media check.
Comment 4 Seth Vidal 2007-11-06 11:01:50 EST
on your running FC5 system could you run: 

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

thanks
Comment 5 Chris Lumens 2007-11-27 16:41:00 EST
*** Bug 335521 has been marked as a duplicate of this bug. ***
Comment 6 Ray Todd Stevens 2007-11-28 07:49:56 EST
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.
Comment 7 Chris Lumens 2007-11-28 09:47:34 EST
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.
Comment 8 Ray Todd Stevens 2007-11-28 10:16:10 EST
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.
Comment 9 Peter 2007-11-29 07:51:01 EST
The question I have is why isn't there a option to just ignore and install?

Comment 10 Ray Todd Stevens 2007-11-29 12:07:49 EST
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.
Comment 11 Peter 2007-11-30 08:14:46 EST
I'm not suggesting ignoring the missing kernel package, but rather for Kernel
packages only, force install.
Comment 12 Ray Todd Stevens 2007-11-30 08:51:49 EST
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.
Comment 13 Peter 2008-04-09 10:00:13 EDT
Without a force option, the system is useless, so your point of "nonbootable" is
mute.

Comment 14 Ray Todd Stevens 2008-04-09 10:24:21 EDT
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.
Comment 15 Peter 2008-04-09 10:50:17 EDT
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.  
Comment 16 Ray Todd Stevens 2008-04-09 11:37:03 EDT
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.
Comment 17 Bug Zapper 2008-05-14 10:49:43 EDT
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
Comment 18 Andy Lindeberg 2008-06-03 16:54:43 EDT
Have you run into the same problem when upgrading to F9?
Comment 19 Ray Todd Stevens 2008-06-03 17:53:25 EDT
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
Comment 20 Bug Zapper 2008-06-16 22:43:21 EDT
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.

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