Bug 318041 - misleading error message when kmdl update isn't available
Summary: misleading error message when kmdl update isn't available
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 7
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Seth Vidal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-04 10:31 UTC by Björn Persson
Modified: 2014-01-21 22:59 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-30 15:31:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
failure after confirmation (3.52 KB, text/plain)
2007-10-08 23:08 UTC, Björn Persson
no flags Details
failure during dependency resolution (7.52 KB, text/plain)
2007-10-08 23:09 UTC, Björn Persson
no flags Details
yum-d5_3.2.6_limit_1_Linux_2.5.22.9 (3.10 KB, text/plain)
2007-10-11 19:14 UTC, Björn Persson
no flags Details
yum-d5_3.2.6_limit_1_Linux_2.5.22.5 (1.99 KB, text/plain)
2007-10-11 19:17 UTC, Björn Persson
no flags Details

Description Björn Persson 2007-10-04 10:31:25 UTC
Description of problem:
I want to have more than two kernel packages installed at the same time. This is
because I have a driver that depends on a certain version, and I want to install
the latest kernel while keeping older versions until the driver is available for
a newer version. To that end I tried raising installonly_limit in yum.conf.

The packages kernel-2.6.22.4-65.fc7 and kernel-2.6.22.5-76.fc7 are currently
installed, and I'm trying to get 2.6.22.9-91.fc7 in. Two versions of the driver
are also installed: one for kernel-2.6.22.4-65.fc7 and one for
kernel-2.6.22.5-76.fc7.

man yum.conf says that the default for installonlypkgs is a list of kernel
packages and that the default for installonly_limit is 2. I concluded that these
two parameters are what makes Yum keep the two latest kernels installed. I first
set installonly_limit to 0 so that Yum would never remove a kernel
automatically. When that didn't work I tried values like 3, 4, 6 and 10000, with
no success.

If installonly_limit is 1 or 2, Yum performs dependency resolution and then
presents a list of packages to install and remove and asks for confirmation. If
I answer "y", Yum fails with the message "ERROR with rpm_check_debug vs
depsolve" because that driver needs /boot/vmlinuz-2.6.22.4-65.fc7. With any
other value for installonly_limit, Yum instead fails during dependency
resolution because the driver needs /boot/vmlinuz-2.6.22.5-76.fc7, so apparently
Yum tries to remove the *newer* of the two installed kernel packages.

Version-Release number of selected component (if applicable):
yum-3.2.5-1.fc7

Comment 1 Seth Vidal 2007-10-08 13:06:54 UTC
Can you publish the output when you set installonly_limit to 0 and when you set
it to 2?

It would be helpful to see the output of yum -d5 for both of those operations.



Comment 2 Björn Persson 2007-10-08 23:08:57 UTC
Created attachment 220311 [details]
failure after confirmation

Well, things have changed a little. I was unforgivably careless and erased the
oldest kernel package, so now there's only one old kernel installed. This has
the effect that yum fails at the later point only when installonly_limit is 1.
When it's 0, 2 or 3 – or presumably any higher number – yum fails at the
earlier point. Apparently it gets through the dependency resolution phase only
if installonly_limit is a positive number less than or equal to the number of
installed kernel packages.

This attachment is what I get when installonly_limit is 1.

Comment 3 Björn Persson 2007-10-08 23:09:25 UTC
Created attachment 220321 [details]
failure during dependency resolution

And this is what I get when installonly_limit is some other number.

Comment 4 Seth Vidal 2007-10-10 00:38:00 UTC
hmm, you're using 3.2.5 - could you grab 3.2.6 from updates-testing and retry,
please? I made some changes to the kernel ver detection in that one which I
think will help.

thanks


Comment 5 Björn Persson 2007-10-11 19:14:55 UTC
Created attachment 224681 [details]
yum-d5_3.2.6_limit_1_Linux_2.5.22.9

Do you detect the version of the running kernel? Then it might be significant
that my results in comment 2 were produced with Linux 2.6.22.9 running. I had
downloaded kernel-2.6.22.9-91.fc7 manually and installed it with RPM, bypassing
Yum. To test yum -d5 I removed that package (and by mistake the oldest one
too), but I didn't reboot.

This time I have tested both with 2.6.22.9 running and with 2.6.22.5 running,
in both cases with only the 2.6.22.5 package installed. Yum is version 3.2.6
from updates-testing.

Under the same circumstances as last time (Linux 2.6.22.9 running but not
installed), Yum 3.2.6 behaves exactly like Yum 3.2.5 did, but under the same
circumstances as when I first reported this bug (Linux 2.6.22.5 runing) it
fails during dependency resolution regardless of the value of
installonly_limit. This is an improvement, but of course not enough as I still
can't get it to install a new kernel.

The only other difference between Yum 3.2.5 and 3.2.6 that I noticed was that
when I ran yum remove kernel-2.6.22.9-91.fc7, Yum 3.2.6 correctly removed the
corresponding version of the ipw3945 driver. With Yum 3.2.5 I had to add that
to the command line.

I see that Yum first tries to find an "update path" for the driver's dependency
on the old kernel package, and then says "converted to install". It seems to do
things in the wrong order. I would think it should convert the kernel update to
installation *before* it tries to resolve dependencies on the old kernel.

Here's the output when installonly_limit is 1 under Linux 2.5.22.9.

Comment 6 Björn Persson 2007-10-11 19:17:45 UTC
Created attachment 224691 [details]
yum-d5_3.2.6_limit_1_Linux_2.5.22.5

And here's the output when installonly_limit is 1 under Linux 2.5.22.5, which
is identical to the output for other values of installonly_limit under both
kernels.

Comment 7 Seth Vidal 2007-10-12 13:58:10 UTC
the dep resolution error is not related to this bug and is a red herring. It
looks like installonly_limit is doing the right thing under 3.2.6.

Please run the following for me:

yum list installed kernel\*
yum list available kernel\*
yum list updates

cat /etc/yum.conf | grep installonly
uname -a

thanks

Comment 8 Björn Persson 2007-10-15 09:53:14 UTC
# yum list installed kernel\*
Loading "refresh-updatesd" plugin
Installed Packages
kernel.x86_64                            2.6.22.5-76.fc7        installed       
kernel-devel.x86_64                      2.6.22.9-91.fc7        installed       
kernel-devel.x86_64                      2.6.22.5-76.fc7        installed       
kernel-headers.x86_64                    2.6.22.9-91.fc7        installed       
# yum list available kernel\*
Loading "refresh-updatesd" plugin
Available Packages
kernel.x86_64                            2.6.22.9-91.fc7        updates         
kernel-debug.x86_64                      2.6.22.9-91.fc7        updates         
kernel-debug-devel.x86_64                2.6.22.9-91.fc7        updates         
kernel-doc.noarch                        2.6.22.9-91.fc7        updates         
kernel-kdump.x86_64                      2.6.21-1.3194.fc7      fedora          
kernel-kdump-devel.x86_64                2.6.21-1.3194.fc7      fedora          
kernel-xen.x86_64                        2.6.20-2936.fc7        updates         
kernel-xen-2.6-doc.noarch                2.6.20-2936.fc7        updates         
kernel-xen-devel.x86_64                  2.6.20-2936.fc7        updates         
# yum list updates
Loading "refresh-updatesd" plugin
Updated Packages
antlr.x86_64                             2.7.7-1jpp.3.fc7.2     updates         
curl.i386                                7.16.4-1.fc7           updates         
curl.x86_64                              7.16.4-1.fc7           updates         
curl-devel.i386                          7.16.4-1.fc7           updates         
curl-devel.x86_64                        7.16.4-1.fc7           updates         
eclipse-cdt.x86_64                       1:3.1.2-8.fc7          updates         
hpijs.x86_64                             1:1.7.4a-6.fc7         updates         
hplip.x86_64                             1.7.4a-6.fc7           updates         
kdebluetooth.x86_64                      1.0-0.34.beta8.fc7     updates         
kernel.x86_64                            2.6.22.9-91.fc7        updates         
libsane-hpaio.x86_64                     1.7.4a-6.fc7           updates         
postgresql-libs.x86_64                   8.2.5-1.fc7            updates         
postgresql-libs.i386                     8.2.5-1.fc7            updates         
# cat /etc/yum.conf | grep installonly
installonly_limit=0
# uname -a
Linux dors.xn--rombobjrn-67a.se 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:08:59 EDT
2007 x86_64 x86_64 x86_64 GNU/Linux

Yum 3.2.6 is not doing the right thing. It fails to install kernel updates. If
the dependency resolution error is unrelated then what prevents Yum from
installing the update?

Comment 9 Björn Persson 2007-11-06 10:38:16 UTC
In case somebody out there cares about this problem, here's an interesting
observation: I have Yum 3.2.7 now, and I discovered by pure accident that Yum
fails to install kernel updates only when there is a driver package installed
for the latest kernel installed. If there are several kernel packages installed,
and driver packages are installed for older kernels but not for the latest
kernel that's installed, then Yum can successfully install a new kernel and
seems to obey installonly_limit.

I'm starting to think that this behavior is actually intended as some kind of
feature, and that the bug that remains in Yum 3.2.7 is only that the error
message is completely backwards and very misleading, but in that case I have to
wonder why Seth Vidal doesn't simply explain this.

Comment 10 Seth Vidal 2007-11-06 14:06:54 UTC
1. yum doesn't run a transaction unless everything in the transaction has been
successfully dependency solved

2. If you are going to use (kmdl) kernel modules you have to use the
kernel-module plugin to make sure you get later ones installed/removed.

That's really what this comes down to.

yum install yum-kernel-module

and see if your problem gets better.




Comment 11 Björn Persson 2007-11-06 23:20:17 UTC
"yum doesn't run a transaction unless everything in the transaction has been
successfully dependency solved"

Neither does RPM. I have always assumed that the definition of "dependency" is
the same in Yum as in RPM. It seemed like a very reasonable assumption given
that the purpose of Yum is to resolve dependencies for RPM. But apparently the
definitions of "dependency" differ, because in this case Yum rejects a
transaction that RPM happily runs.

OK, so Yum tries to ensure that kernel modules get updated together with the
kernel. That's a good idea, but something must be done about the error message.
It says "Missing Dependency: X is needed by package Y". Normally that means that
Yum tried to install Y but X wasn't available. When both X and Y are already
installed the only way I can read it is that Yum tried to remove X. Therefore I
thought Yum ignored installonly_update and tried to remove old kernel packages.

When X is in the installonlypkgs list the message should instead be "Missing
co-update: An update to kernel won't be installed because there is no
corresponding update to Y."

Comment 12 Tim Lauridsen 2007-11-07 12:48:46 UTC
"Missing Dependency: X is needed by package Y"
Can also mean that you cant update packet X to a new version, because packet Y
need the old version of X.
There is a lot of cases, so it is hard to give a message describing the cause of
why there is a missing dependency.
Another way to read it is.
If where do this Transaction then we will have a
"Missing Dependency: X is needed by package Y"
So this is why we don't do it, because we don't want to break your system. 

Comment 13 Björn Persson 2007-11-07 18:47:04 UTC
That's *exactly* what I thought it meant, and that's why I thought Yum ignored
installonly_update and tried to remove old kernel packages.

When X is in the installonlypkgs list, then Yum is *not* supposed to update X;
it's supposed to *install* the new version *without* removing the one that's
already installed. That Y needs the old X is then *not* a problem in itself,
because the old X *will still be there*. The dependency will *not* be missing.

If, on the other hand, X were to be updated the usual way, then the dependency
would be broken, and now yum says the dependency would be broken, so I draw the
conclusion that Yum tried to update X the usual way. That conclusion is wrong,
and therefore the message is wrong.

You say it's hard? Yes, writing programs of good quality is hard. If it were
easy there wouldn't be so many companies selling garbage and calling it software.

Comment 14 Seth Vidal 2008-03-12 14:48:01 UTC
Björn,
 Your hostility to Tim is not necessary or warranted. We're trying to solve this
problem but it is not  a trivial issue to work with.

I ask that you test the behavior you're seeing on yum 3.2.12 from rawhide and
let us know if the problem persists. We've fixed a lot of problems since november.

Comment 15 Bug Zapper 2008-05-14 14:37:11 UTC
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


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