Bug 103645
| Summary: | "up2date -i ntp" crashes with python errors about deps? | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux Beta | Reporter: | Ben Russo <brusso> |
| Component: | up2date | Assignee: | Adrian Likins <alikins> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fanny Augustin <fmoquete> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | beta1 | CC: | gafton, mihai.ibanescu |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-21 18:58:24 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
up2date -i kdebase also fails with similar error messages.
up2date -i tftp works just fine.
The exact output of up2date -i kdebase is:
[root@bens-test root]# up2date -i kdebase
Fetching package list for channel: redhat-linux-severn-i386-9.0.93...
########################################
Fetching package list for channel: redhat-linux-severn-i386-9.0.93-updates...
########################################
Fetching Obsoletes list for channel: redhat-linux-severn-i386-9.0.93...
Fetching Obsoletes list for channel: redhat-linux-severn-i386-9.0.93-updates...
Fetching rpm headers...
########################################
Testing package set / solving RPM inter-dependencies...
Traceback (most recent call last):
File "/usr/sbin/up2date", line 1149, in ?
sys.exit(main() or 0)
File "/usr/sbin/up2date", line 748, in main
fullUpdate, dryRun=options.dry_run))
File "/usr/sbin/up2date", line 1015, in batchRun
batch.run()
File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 64, in run
self.__dryRun()
File "/usr/share/rhn/up2date_client/up2dateBatch.py", line 134, in __dryRun
self.percentCallback)
File "/usr/share/rhn/up2date_client/up2date.py", line 482, in dryRun
ret = depsolve.solvedep()
File "/usr/share/rhn/up2date_client/depSolver.py", line 634, in solvedep
ret = self.process_deps(deps)
File "/usr/share/rhn/up2date_client/depSolver.py", line 601, in process_deps
changed = self.__dependencies(dependencies)
File "/usr/share/rhn/up2date_client/depSolver.py", line 447, in __dependencies
refreshCallback = self.refreshCallback)
File "/usr/share/rhn/up2date_client/depSolver.py", line 94, in solveDep
ret = source.solveDep(unknowns, availList, refreshCallback)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line 42,
in solveDep
self.getSolutions(unknowns)
File "/usr/share/rhn/up2date_client/repoBackends/genericSolveDep.py", line
190, in getSolutions
repoChannels = rhnChannel.selected_channels.getByType(self.type)
AttributeError: 'NoneType' object has no attribute 'getByType'
*** This bug has been marked as a duplicate of 103558 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |
Did minimal install of RedHat 9.0.93 (severn). updated RHN cert, imported RedHat GPG key, rhnreg_ks to my enterprise account, set channel subscription to 9.0.93 upates. did full up2date -u (worked only after changing "useGPG=1" to "useGPG=0" ) up2date -i rpmdb-redhat (it worked) did up2date -p (it worked) did rpm -qa (it worked) did up2date -i ntp (it died with many python traceback errors about object type dependencies) up2date -l, up2date -u, and up2date -p all work fine, I can even install other packages with up2date -i, just not ntp.... I used freshrpms apt-get to install a RedHat 9 ntp rpm, which also fetched the libcap dependency. Then I did up2date -u and it upgraded both libpcap and ntp to the 9.0.93 version... Version-Release number of selected component: up2date-3.9.20-2 How reproducible: Always Steps to Reproduce: 1. Minimal install of 9.0.93 2. Update RHN CERT, import RedHat GPG key, Register with RHN, subscribe to 9.0.93 updates channel, up2date -u 3. up2date -i ntp (this produces up2date crash with python trace errors) Expected Results: up2date either successfully fetches ntp and libcap, or up2date produces human readable errors (not "programmer readable" but "human readable") explaining why the transaction did not work. I mean heck maybe the NTP rpm is corrupt and it isn't an issue with up2date? But how would I know that? Additional info: I also tried troubleshooting the problem by doing rm -rf /var/spool/up2date/* rm -f /var/lib/rpm/__db.00* and then trying "up2date -i ntp" again, but it didn't help.