From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) Description of problem: At Step 3 in registration for up2date (up2date --register), all fields show 'ERROR' for data, and I get a traceback in the terminal window: Traceback (most recent call last): File "/usr/share/rhn/up2date_client/gui.py", line 759, in onProfilePagePrepare self.hardware = hardware.Hardware() File "/usr/share/rhn/up2date_client/hardware.py", line 511, in Hardware ret = read_network() File "/usr/share/rhn/up2date_client/hardware.py", line 339, in read_network hostname, ipaddr = findHostByRoute() File "/usr/share/rhn/up2date_client/hardware.py", line 319, in findHostByRoute hostname = socket.gethostbyaddr(intf)[0] socket.herror: (1, 'Unknown host') I just did an install (not an update) of Test3 on an IBM Thinkpad 600X. I had Test2 on it, and registration worked fine then. Version-Release number of selected component (if applicable): up2date 4.1.7-1 How reproducible: Always Steps to Reproduce: 1. Run up2date --register 2. Enter data in windows...use an existing account 3.Check "Included Information" in Step 3: Register a System Profile - Hardware Actual Results: Window shows "ERROR" (without the quotes) as the data value in all fields in the "Included Information" box. Traceback occurs in Terminal window. Expected Results: Various valid values in each field Additional info:
interesting. Could you send me the output of /sbin/ifconfig and the output of the testhardware.py script attached to this bug report?
Created attachment 95210 [details] test script for testing network hostname
Created attachment 95246 [details] Output of testhardware.py
Created attachment 95247 [details] Output of ifconfig
I see the same problem on an IBM Intellistation M-Pro 6868-35U with a freshly installed test3. I also have the same output from testhardware.py. Only (small) difference is that my eth0 is configured to IP 192.168.1.100 by DHCP from my router. I also tried testhardware.py on a similar box that is set up with RH9 and there it works fine, could this be a bug in the library python uses on test3? Is there any more info you would like from me?
This occurs when the ip address of the machine does not resolve to a host name. Usually this is a result of using a home router since they don't provide a DNS lookup for the local 192.168.*.* addresses. When up2date tries to get a host name it fails. The new version up2date-4.1.10-1 seems to try to fix this problem, but causes another. In hardware.py in the function findHostByRoute() (line 321) the print statement is broken: print _("unable to resolve hostname for for this machine") Removing the underscore and parentheses fixes this problem, though actually removing the print statement completely would probably be the way to go. The host is set to "unknown" so the user will still see this when it is displayed. By fixing this I was able to complete registration successfully. Since Fedora seems to be implementing a lot of tools in Python I think it's necessary for all the code to be run through some sort of syntax checker prior to releasing packages. This will ensure that errors like this one get caught before the package is released, rather than at run-time. I'm not really sure where to put this suggestion since it relates to many projects, so if someone knows of the appropriate place to suggest this I'll file it there.
yeah, print statement removed. seems to work better now, got some testing in. And since fedora will never actually hit these code paths (only hit when registering, which is not used on fedora), looks closed to me. 4.1.12 has the print removed.