Red Hat Bugzilla – Bug 476714
Preupgrade anaconda exception: PackageSackError: No Package Matching kernel
Last modified: 2014-01-21 18:07:15 EST
Created attachment 327136 [details]
Log from anaconda.
When upgrading Fedora 9 to 10 using preupgrade, upon reboot anaconda immediately failed with the exception:
PackageSackError: No Package Matching kernel
See the attached anacdump.txt for dull details. The preupgrade utility did not report any errors.
I updated to preupgrade-1.0.1-1.fc9 from koji and tried again but it did not help.
That log shows all F9 packages being installed. For example:
How in the world did you get F9 packages for an upgrade to F10?
Will - the install.log you're seeing there is from his initial F9 installation. On upgrades, anaconda grabs that and puts it into the traceback as well. We haven't even gotten to upgrading to F10 packages when this traceback is hit.
During one of my very first tests I got the following error message printed to the screen as anaconda was starting:
error: db4 error(22) from dbenv->open: invalid argument
There were more similar lines printed that also referred to file paths and stuff, but the anaconda exception dialog covered them up before I had time to copy them down on paper.
I've tried starting anaconda several times more but the messages have not appeared again (or if they do, they get scrolled of the screen or overwritten before I have a chanse to see them).
(In reply to comment #3)
> During one of my very first tests I got the following error message printed to
> the screen as anaconda was starting:
> error: db4 error(22) from dbenv->open: invalid argument
> There were more similar lines printed that also referred to file paths and
> stuff, but the anaconda exception dialog covered them up before I had time to
> copy them down on paper.
Okay, if that log isn't from F10.. do you have kernel-xen installed? If so, remove it. See the Common Bugs page for details:
Nope I don't use xen, this is what I have installed related to kernels:
$ rpm -qa | grep ^kernel
I also have the nvidia driver rpm from RPM Fusion installed in case that matters (naughty me):
$ rpm -qa | grep kmod
I just noticed, there is no kernel package in the /var/cache/yum/preupgrade/packages directory, might that be the problem?
Yes, that'd do it. But why didn't preupgrade fetch a kernel package, I wonder?
Can you run 'preupgrade' from a terminal window and look for any messages about 'kernel'?
Created attachment 327165 [details]
Output from: preupgrade-cli --verbose "Fedora 10 (Cambridge)"
Preupgrade doesn't say a peep about kernels, I'm attaching the full output in case it helps.
Created attachment 327171 [details]
My yum config files
I noticed from the output that preupgrade makes use of my yum config, seems risky, who knows what kind of wacky stuff I might have put there? :)
I'm attaching all yum related config files just in case.
The only thing of note is that I've excuded gdm becasue I downgraded it to the Fedora 8 version to get gdmsetup back. Looking in my cache dir I see that preupgrade didn't download a new gdm package. Not good, I would rather like to have a new gdm. Unless ofcourse gdmsetup is still missing...
What makes you think preupgrade is using your yum config? It doesn't use the system's yum config at all.
Anyway, I just noticed that you have:
The base F10 kernel is kernel-18.104.22.168-117.fc10 - which is *older* than your F9 kernel, according to RPM. That's why preupgrade isn't bothering to fetch it.
But - anaconda really *wants* to install a new kernel package to ensure the system will work. So it dies when it can't find a kernel package in the preupgrade repo.
I think we're going to need to force preupgrade to download a kernel package, no matter what.
Alternately, we could solve this by enabling the updates repo(s) during preupgrade - which is something I was planning to do anyway.
In the meantime, if you need a workaround, you could download the current F-10 kernel package (kernel-22.214.171.124-134.fc10) and put it into the preupgrade/packages directory, then re-run preupgrade, and your upgrade *should* complete successfully.
(In reply to comment #10)
> What makes you think preupgrade is using your yum config? It doesn't use the
> system's yum config at all.
Well, the message "Excluding Packages in global exclude list" and the fact that a gdm package is nowhere to be seen in /var/cache/yum/preupgrade/packages and I have exclude=gdm in yum.conf made me put 2 and 2 and 2 together...
I have gdm-2.20.5-3.fc8.x86_64 installed, but F10 ships gdm-2.24.0-12.fc10.x86_64 so preupgrade really should have downloaded it right?
I'll try putting both a kernel and gdm in the packages dir and give preupgrade a spin tomorrow, thanks for the tip!
Manually adding the kernel package worked like a charm. Now I'm a happy F10 camper. Thanks!
Yikes! It took me forever to find this solution, I've been trying to upgrade to Fedora 10 for days! I also tried downloading the DVD but installing from that gave me the same error message, is it possible it could have the same show stopper bug or did my preupgrade downloads take precedence over that?
I have no idea how to "enable the updates repo(s) during preupgrade" but I definitely would have thought the latest updates were being downloaded already.
I personally solved the problem by uninstalling my two newest kernels. Thanks guys.
*** Bug 477599 has been marked as a duplicate of this bug. ***
preuprgade-cli (PreUpgrade - 1.0.0 yum - 3.2.21) in fc9 fails with "PackageSackError: No Package Matching kernel" although preupgrade-cli downloaded a kernel package which is saved in the /var/cache/yum/preupgrade/packages directory
I have run into a similar error with preupgrade.
Any packages that are excluded in /etc/yum.conf produce this error when running preupgrade:
<package_name> cannot be opened due to a missing file, corrupted package or corrupted media.
When I check in the /var/cache/yum area there are no packages or headers for these packages.
The packages that are being excluded in /etc/yum.conf are custom-compiled with special options so how should we handle this type of situation at distro upgrade?
If the upgrade needs to install the 'generic' packages from the installation then
we need to make sure that we do not lose any of the configurations for the custom packages compilations. I guess once the new upgrade is in place then we can recompile these packages and install them. Although, I'd rather anaconda just ignore the custom packages altogether and we could deal with that issue after the upgrade and not have to deal with it during installation.
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9. 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 '9'.
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 9'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 9 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 to the applicable version. 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.
The process we are following is described here:
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 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.