Bug 61457 - up2date-2.7.46-7.x.1 - RPM dep error - traceback
up2date-2.7.46-7.x.1 - RPM dep error - traceback
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-19 18:14 EST by James Manning
Modified: 2015-01-07 18:55 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-05-08 16:57:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the full traceback during up2date -u (2.62 KB, text/plain)
2002-03-19 18:15 EST, James Manning
no flags Details
up2date-2.7.46-7.x.2 -u run with traceback on lvs01 (2.61 KB, text/plain)
2002-03-20 15:59 EST, James Manning
no flags Details
/var/log/up2date entries from lvs01 up2date -u traceback run (1.41 KB, text/plain)
2002-03-20 16:01 EST, James Manning
no flags Details

  None (edit)
Description James Manning 2002-03-19 18:14:14 EST
new up2date, RH 7.1 machine, traceback within kernel dependencies

I'll attach the full traceback in case it helps, but basically:

up2date_client.up2date.UnsolvedDependencyError: RPM dependency error.  The message was:
Packages [['kernel-smp', '2.4.9', '31', ''], ['kernel-debug', '2.4.9', '31', ''], ['kernel-enterprise', '2.4.9', '31', ''], ['kernel', '2.4.9', '31', '']] provides dep 
[['kernel-smp', '2.4.9', '31', ''], ['kernel-debug', '2.4.9', '31', ''], ['kernel-enterprise', '2.4.9', '31', ''], ['kernel', '2.4.9', '31', '']] but is not availble for install 
based on client config

porivoweb02:/var{1060}# rpm -qa|grep -i kernel
kernel-smp-2.4.2-2
kernel-2.4.2-2
kernel-headers-2.4.2-2
porivoweb02:/var{1061}# rpm -q redhat-release
redhat-release-7.1-1

I admit that I don't get why enterprise and debug are in there - weird
Comment 1 James Manning 2002-03-19 18:15:42 EST
Created attachment 49064 [details]
the full traceback during up2date -u
Comment 2 Adrian Likins 2002-03-19 18:28:11 EST
grumble.

Yeah, thats broke. A new exception that doesnt get caught in
the cli. grumble.

The update would of failed anyway and given you an error
message, but ugh, it shouldnt traceback. 

grumble.
Comment 3 James Manning 2002-03-19 18:48:39 EST
Ok, now I'm lost - why would the update fail?  I don't get what's broken.

IOW, does this error/traceback indicate a problem on my system?  And if so, what?

At this point I can only imagine manually updating kernel* and trying again, 
but I can delay that to confirm this bug is fixed :)
Comment 4 Adrian Likins 2002-03-19 22:36:02 EST
Something seems to be trying to pull kernel/kernel-smp and kernel-enterprise
in as deps, and they are on the pkg skip list.  

How are you invoking up2date?

I'm actually having trouble reproducing this as well, though
I can see how if you hit that code path it will give the traceback
mentioned. I'm just not sure how your getting there with the 
current set of packages.
Comment 5 James Manning 2002-03-20 15:57:01 EST
ok, it's happening on another machine now (lvs01, the machine I was trying to
schedule the RHN update for as a test case for bug 61463, which is why it failed
on those 59 scheduled actions for errata updates :)

traceback coming in another attachment, although it's basically the same.

The freaky thing is that the other machine had both kernel and kernel-smp
installed, but this one doesn't, but kernel-smp is still showing up in the RPM
dep error of the traceback.  Ick.

[root@lvs01 /root]# cat /etc/redhat-release
Red Hat Linux release 7.1 (Seawolf)
[root@lvs01 /root]# rpm -qa|grep kernel
kernel-2.4.2-2
kernel-headers-2.4.2-2
kernel-source-2.4.2-2
Comment 6 James Manning 2002-03-20 15:59:06 EST
Created attachment 49264 [details]
up2date-2.7.46-7.x.2 -u run with traceback on lvs01
Comment 7 James Manning 2002-03-20 16:00:42 EST
hmmm checking the up2date log, looks like kernel-drm might the offender.

I'll attach the up2date log from the -u that tracebacks on lvs01
Comment 8 James Manning 2002-03-20 16:01:27 EST
Created attachment 49265 [details]
/var/log/up2date entries from lvs01 up2date -u traceback run
Comment 9 James Manning 2002-03-20 16:38:04 EST
in case it helps, after doing the simple fix I describe in bug 61511 the output
makes a little more sense for the error:

Packages [['kernel-smp', '2.4.9', '31', ''], ['kernel-debug', '2.4.9', '31', ''], ['kernel-enterprise', '2.4.9', '31', ''], ['kernel', '2.4.9', '31', '']] provides dep 
kernel-drm but is not availble for install based on client config

So it is indeed kernel-drm that's required (now to figure out what requires that from
the other packages).  But there's a VERY SCARY implication here.  Going from
the code in up2date.py:

            # in the future this should anaylize the possible solutions
            # and pick the "best" one. But since in theory, any of them
            # should work, grab the first

The Very Bad Thing is that in this case, the SMP kernel (for a non-SMP box) happens
to be the first entry in the array of packages that can satisfy this dep.  The UP is there, too,
but not at the front of the array.  AFAICT, this will mean a breakage as the SMP
kernel will get added as a requirement :(

This may be cleaned up in other sections of code that I don't see now, just looks
like a potential problem from here, one that the comment seems to indicate
was a situation that may crop up :)
Comment 10 Adrian Likins 2002-03-20 17:27:33 EST
hmm, sorta.

But, kernel-smp wont be in the available package list on
a non-smp box (assuming the non-smp box doesnt have a smp kernel
installed), but will raise the dep error your seeing.

First impression is that I need to iterate over that list until
I get one that's available at the very least. That still kind
of assumes that all the packages listed are legit for meeting
that dep. 

But for this case, I need to iterate over all of them, and install
all of them that are available. But... in the fuzzy sense, I only
need to install the ones that are already installed.

But installing all of them in the general case is just wrong, as
in the case of "smtpdaemon". I'll get a list of "postfix" and "sendmail",
nethier of which is installed, both of which are valid and available, but
installing both of them is invalid. 

This is gonna take some thinking...
Comment 11 Adrian Likins 2002-05-08 16:57:51 EDT
this is still a bit up in the air...

but I'll probabaly add in a better heuristic for handling
this case as part of the current rewrite
Comment 12 James Manning 2002-05-17 13:09:43 EDT
while handling the particular dependency issues is still valuable, the initial
bug report here is about an actual traceback, one that wrapper.py's been
catching for awhile now, so I'm closing this one

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