Bug 108695
| Summary: | up2date TypeError: iteration over non-sequence | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Illtud Daniel <illtud> |
| Component: | up2date | Assignee: | Adrian Likins <alikins> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fanny Augustin <fmoquete> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | gafton, mihai.ibanescu, paul |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-08-24 20:54:08 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: | |||
rm -rf /var/spool/up2date/* and try again. OK through the help of a friend I was able to fix the problem although I do not know what caused it in the first place. Here are the steps that worked for me although there may be a shorter way to do this. 1. Execute the command rm -rf /var/spool/up2date/* (Note: the command the RH tech gave me earlier was rm -rf /var/spool/up2date which forces you to recreate the up2date directory otherwise up2date errors with out it.) 2. delete the systemid file: rm /etc/sysconfig/rhn/systemid 3. delete the system from the RedHat Network 4. run up2date again which will re-register the system. I managed to get going again by just executing rhn_register, which complained that I seemed to already be registered, but continuing with the process fixed the up2date problem as well. I'm sorry, Adrian, I missed your message about clearing out the up2date registry - we've moved mailservers (to the machine that was having the up2date problem!) and a few messages fell between the cracks. Thanks for your help. The root of this is a system not being assigned a package channel. Most often, this indicates a lack of RHN entitlements for that channel. Fix is to verify the server has a channel to it assigned via the website (or that there are enough entitlements available for that channel) In addition, current clients handle this case more gracefully. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Description of problem: up2date <package> or up2date -u fails with the following traceback: # up2date -u Traceback (most recent call last): File "/usr/sbin/up2date", line 993, in ? main() File "/usr/sbin/up2date", line 720, in main fullUpdate, dryRun=options.dry_run)) File "/usr/sbin/up2date", line 893, in batchRun batch.run() File "up2dateBatch.py", line 57, in run File "up2dateBatch.py", line 88, in __findPackagesToUpdate File "packageList.py", line 88, in run File "packageList.py", line 116, in addObsoletePackages TypeError: iteration over non-sequence This probably has to do with an oops on our RHN subscription, where this system was stripped of its entitlements without expiration or warning. The system is now fully entitled, but up2date is broken. Version-Release number of selected component (if applicable): up2date-3.1.23.2-1 How reproducible: Always Steps to Reproduce: 1.run up2date <package> or -u 2.???? 3.Profi^W err... traceback message appears. Actual Results: See traceback message above. Expected Results: up2date working? Additional info: