Bug 107548 - up2date fails on system details
Summary: up2date fails on system details
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: rawhide
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-20 14:32 UTC by Don Vanco
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-08-27 00:50:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
test script to test hostname/if detection code (215 bytes, text/plain)
2003-10-22 01:43 UTC, Adrian Likins
no flags Details

Description Don Vanco 2003-10-20 14:32:16 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Description of problem:
up2date gets a scritp error when trying to look at system details:

[root@localhost up2date]# rpm -q up2date
up2date-4.1.7-1

[root@localhost up2date]# rpm -q up2date-gnome
up2date-gnome-4.1.7-1

[root@localhost up2date]# up2date -p
You need to register this system by running `up2date --register` before using 
this option

[root@localhost up2date]# up2date --register
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')

[root@localhost up2date]# rhn_check
ERROR: unable to read system id.



Version-Release number of selected component (if applicable):
up2date-4.1.7-1; up2date-gnome-4.1.7-1

How reproducible:
Always

Steps to Reproduce:
1. run up2date (in GUI or text mode)
2.
3.
    

Actual Results:  see above

Expected Results:  CPU, Processor, etc

Additional info:

Comment 1 Don Vanco 2003-10-20 14:45:43 UTC
output from TUI:
[root@mediamaker root]# rhn_register --nox
Traceback (most recent call last):
  File "/usr/sbin/rhn_register", line 1183, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/rhn_register", line 705, in main
    tui.main()
  File "tui.py", line 1097, in main
  File "tui.py", line 1041, in run
  File "tui.py", line 613, in __init__
  File "hardware.py", line 511, in Hardware
  File "hardware.py", line 339, in read_network
  File "hardware.py", line 319, in findHostByRoute
socket.herror: (1, 'Unknown host')



Comment 2 Adrian Likins 2003-10-22 01:42:12 UTC
can you attach output of:

/sbin/ifconfig

and `nslookup $IP`
where $IP is the ip address for the interfaces /sbin/ifconfig shows?

also, there is a "testhostname.py" script attached, can
you run it and post the output?

Comment 3 Adrian Likins 2003-10-22 01:43:08 UTC
Created attachment 95367 [details]
test script to test hostname/if detection code

Comment 4 Don Vanco 2003-10-22 13:55:20 UTC
Resolved (well, I'm farther along anyway) - see below for details

FYI - box is served via DHCP on a Windoze Network - getting the hostname set 
via DHCP would take a minor act of Congress..

(first - I did what you asked)....
ifconfig:
eth0      Link encap:Ethernet  HWaddr 00:30:1B:AF:2D:EF
          inet addr:172.27.17.152  Bcast:172.27.19.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26956 errors:0 dropped:0 overruns:0 frame:0
          TX packets:262 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2827625 (2.6 Mb)  TX bytes:27652 (27.0 Kb)
          Interrupt:18 Base address:0x3000

(lo is also present and looks as expected)


# nslookup 172.27.17.152 -sil
Server:         192.168.0.36
Address:        192.168.0.36#53

** server can't find 152.17.27.172.in-addr.arpa: NXDOMAIN



# dig 172.27.17.152
; <<>> DiG 9.2.2-P3 <<>> 172.27.17.152
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6761
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;172.27.17.152.                 IN      A

;; AUTHORITY SECTION:
.                       86400   IN      SOA     a.root-servers.net. 
nstld.verisign-grs.com. 2003102200 1800 900 604800 86400

;; Query time: 111 msec
;; SERVER: 192.168.0.36#53(192.168.0.36)
;; WHEN: Wed Oct 22 09:37:19 2003
;; MSG SIZE  rcvd: 106



./testhostname.py
Traceback (most recent call last):
  File "./testhostname.py", line 9, in ?
    hostname = socket.gethostbyaddr(intf)[0]
socket.herror: (1, 'Unknown host')

Thinking that this was "not right I launched redhat-config-network.
When I first configured the system I had used the GUI tool to set the hostname 
of this box - but I did so by entering the hostname via the "DNS" tab of the 
GUI tool - upon restarting netwrok services the hostname took.
To resolve GNOME complaints upon logging in I added the system hostname 
to /etc/hosts in the loopback line.
What seems to have resolved this scritping issue is going back into R-C-N and 
editing the eth0 interface on the "Devices" tab.

Now:
./testhostname.py
172.27.17.152
mediamaker.pios.com

HOWEVR - 
once I set up the RHN profile I get an error telling me that I have an invalid 
combination of architecture and OS (0.95 and i686-redhat-linux) and that there 
are no channels for me to subscribe to - I have removed and reinstalled rhn-
applet (2.1.1) but that has not helped.

Comment 5 Don Vanco 2003-10-22 13:57:01 UTC
What seems to have resolved this scritping issue is going back into R-C-N and 
editing the eth0 interface on the "Devices" tab.
(doh!)
....AND entering the hostname as part of the config here.

Comment 6 Adrian Likins 2003-10-22 16:23:02 UTC
okay, more or less what I expected. next release will have
code to not error out on this case. 4.1.9 I belive has
the change in it.

as far as the registration goes, there are no RHN channels for
fedora 0.95. The default up2date should include a /etc/sysconfig/rhn/sources
file that points at a yum repo for rawhide (which of course, is disabled
today temporarily). If you still have a /etc/sysconfig/rhn/sources
from earlier up2dates, you can copy /etc/sysconfig/rhn/sources.rpmnew
to /etc/sysconfig/rhn/sources and run up2date. No registration is
required. (noting of course, the caveat about rawhide not actually
being avaialble temporarily)

Comment 7 Barry K. Nathan 2004-07-14 15:49:47 UTC
This bug seems fixed to me in Fedora Core 1 final (and later). Given
the setup of my home network, I'm sure I would have hit this bug many
times by now if it was still present.


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