Bug 107548 - up2date fails on system details
up2date fails on system details
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Adrian Likins
Fanny Augustin
Depends On:
  Show dependency treegraph
Reported: 2003-10-20 10:32 EDT by Don Vanco
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-26 20:50:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Don Vanco 2003-10-20 10:32:16 EDT
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

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

[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:

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

Actual Results:  see above

Expected Results:  CPU, Processor, etc

Additional info:
Comment 1 Don Vanco 2003-10-20 10:45:43 EDT
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
  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-21 21:42:12 EDT
can you attach output of:


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-21 21:43:08 EDT
Created attachment 95367 [details]
test script to test hostname/if detection code
Comment 4 Don Vanco 2003-10-22 09:55:20 EDT
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)....
eth0      Link encap:Ethernet  HWaddr 00:30:1B:AF:2D:EF
          inet addr:  Bcast:  Mask:
          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 -sil

** server can't find NXDOMAIN

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

;                 IN      A

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

;; Query time: 111 msec
;; WHEN: Wed Oct 22 09:37:19 2003
;; MSG SIZE  rcvd: 106

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.


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 09:57:01 EDT
What seems to have resolved this scritping issue is going back into R-C-N and 
editing the eth0 interface on the "Devices" tab.
....AND entering the hostname as part of the config here.
Comment 6 Adrian Likins 2003-10-22 12:23:02 EDT
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 11:49:47 EDT
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.