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
Created attachment 49064 [details] the full traceback during up2date -u
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.
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 :)
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.
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
Created attachment 49264 [details] up2date-2.7.46-7.x.2 -u run with traceback on lvs01
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
Created attachment 49265 [details] /var/log/up2date entries from lvs01 up2date -u traceback run
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 :)
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...
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
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