This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 449120 - dhclient fails to restart for 'service network restart'
dhclient fails to restart for 'service network restart'
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
9
i386 Linux
low Severity low
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-30 11:45 EDT by Beartooth Bugzapper
Modified: 2008-06-24 09:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-24 09:49:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
came up when I ssh'd into a LAN machine after a connection outage (843 bytes, text/plain)
2008-05-30 11:45 EDT, Beartooth Bugzapper
no flags Details
service restart tests (3.34 KB, text/plain)
2008-06-13 10:55 EDT, Frank Murphy
no flags Details

  None (edit)
Description Beartooth Bugzapper 2008-05-30 11:45:06 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Beartooth Bugzapper 2008-05-30 11:45:06 EDT
Created attachment 307209 [details]
came up when I ssh'd into a LAN machine after a connection outage
Comment 2 David Cantrell 2008-05-30 16:29:42 EDT
Interesting...will have to see if I can recreate that here and figure it out.
Comment 3 Beartooth Bugzapper 2008-05-31 11:43:11 EDT
   Here's all I have. TopBlack is my own #1 machine, at 192.168.0.3; Msgv is my 
wife's, downstairs, at 192.168.0.2. Both are running F8.

    We had had a connection outage (which turned out, to my embarrassment, to have 
been caused by the surge protector serving my 10/100 ethernet switch getting 
switched off somehow -- in case that's relevant). 

  With our connection restored, I tried to ssh into her machine to run yum update. 
Here's what I saw : 

[btth@TopBlack ~]$ ssh 192.168.0.2
The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
RSA key fingerprint is a3:89:9a:be:38:66:1a:85:b6:cc:79:02:1b:37:6b:8b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.2' (RSA) to the list of known hosts.
btth@192.168.0.2's password: 
Last login: Sat May  3 19:09:18 2008 from 192.168.0.4
[btth@Msgv ~]$ su - 
Password: 
[root@Msgv ~]# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...dhclient(9093) is already running - exiting. 
This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.
Please report for this software via the Red Hat Bugzilla site:
    http://bugzilla.redhat.com
exiting.
 failed.
                                                           [FAILED]
[root@Msgv ~]# yum clean all
Cleaning up Everything
[root@Msgv ~]# yum update

    [yum update then completed normally.]

Comment 4 Beartooth Bugzapper 2008-05-31 12:16:47 EDT
   Surprise! Got it again.

   I booted another i386 machine, my #2, running F9. NetworkManager Applet 0.7.0 
showed No Connection. I logged one tab of my gnome terminal in to root, and did 
service network restart, as before with my wife's machine. The message appears to be 
identical. 



 
Comment 5 Beartooth Bugzapper 2008-06-02 13:16:50 EDT
Update : it seems to be doing it regularly.

   Once booted and connected the #2 machine ran fine -- I'm on it now.

   I put gpk through its paces, adding and removing many apps; closed it; rebooted 
just now to do a yum update (to check on gpk), and found the machine not connected.

   Again I tried "service network restart." It gave me the message (copied below, 
in case there's any change I don't see). 

   When it got to "exiting failed," however, NetworkManager Applet had turned into 
its two blue balls chasing one another; which promptly became a connection.

   I did "yum clean all" followed by "rpm --rebuilddb."

   "Yum clean all" reported success in a few seconds, as usual. "Rpm --rebuilddb" 
took quite a while, as it often does, and also finished normally. (Interpolating 
it into updates is my way of remembering to do it.) 

    Then I did "yu update," which also completed normally.

[btth@hbsk ~]$ su - 
Password: 
[root@hbsk ~]# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...dhclient(3601) is already running - exiting. 

This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.

Please report for this software via the Red Hat Bugzilla site:
    http://bugzilla.redhat.com

exiting.
 failed.
                                                           [FAILED]
[root@hbsk ~]#
Comment 6 Frank Murphy 2008-06-13 09:40:38 EDT
Also getting this:
[root@frank-03 ~]# service network restart
Shutting down interface eth0:                              [  OK  ]
Shutting down loopback interface:                          [  OK  ]
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...dhclient(3901) is already running - exiting. 

This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.

Please report for this software via the Red Hat Bugzilla site:
    http://bugzilla.redhat.com

exiting.
 failed.
                                                           [FAILED]


This is an F9 u\g from F8 using pre-upgrade XFCE Environment
Comment 7 Frank Murphy 2008-06-13 09:43:37 EDT
dhclient-4.0.0-14.fc9.i386
Comment 8 Frank Murphy 2008-06-13 10:55:37 EDT
Created attachment 309220 [details]
service restart tests

If network manager is running "service network restart" fails.
if NM disabled, "service network restart" ok on 2nd attempt and thereafter
Comment 9 Charles R. Anderson 2008-06-21 10:58:35 EDT
Changing to version 9.
Comment 10 Beartooth Bugzapper 2008-06-21 14:44:24 EDT
   I gave up trying to run F9 on the machine where that was happening, and re-
installed F8. On reboot, after a day's use of F8, it came up not connected. I 
got this, with a difference : 

=============================================
[root@Tpblk btth]# service network start
Bringing up loopback interface:                            [  OK  ]
Bringing up interface eth0:  
Determining IP information for eth0...dhclient(1799) is already running - 
exiting. 
This version of ISC DHCP is based on the release available
on ftp.isc.org.  Features have been added and other changes
have been made to the base software release in order to make
it work better with this distribution.
Please report for this software via the Red Hat Bugzilla site:
    http://bugzilla.redhat.com
exiting.
 failed.
                                                           [FAILED]
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
RTNETLINK answers: File exists
[root@Tpblk btth]# 
================================================

   The difference is that the little red X remains by the icon for the Network 
Manager applet -- even though I am in fact connected. And, of course, running 
F8, not F9.
Comment 11 David Cantrell 2008-06-21 15:02:47 EDT
Are you using NetworkManager and the network service?  If so, that won't work.  You need to use one 
or the other, not both.  As of Fedora 9, we enabled NetworkManager by default, so you need to make 
sure you are not using the network service anymore:

chkconfig network off

If you must use a mix of the network service and NetworkManager, you need to edit the ifcfg-ethX files 
for the devices you do not want NetworkManager to control.  For those devices you want controlled by 
the network service, put this line in the file:

NM_CONTROLLED=no

This has been happening to some people on upgrades, but the main thing is to make sure only one 
thing (either NetworkManager or the network service) is controlling the interfaces, otherwise you will 
get multiple dhclient processes launching.
Comment 12 Beartooth Bugzapper 2008-06-21 15:44:14 EDT
  Confusion thrice compounded! The machine with the problem (my #1) has tried 
twice to run F9, been defeated both times, and now runs F8 again, not F9.

   Nevertheless, I tried putting 

NM_CONTROLLED=no

at the bottom of /etc/sysconfig/network-scripts/ifcfg-eth0

   I also went into /usr/bin/system-config-services (from the Main Menu launcher, 
which I keep on a panel), where I turned off NetworkManager

   Now *neither* NM *nor* service network (re)start will connect!

   I'm not *trying* to mix them, though I may be doing it. I'm simply trying to 
use what has "just worked" in the past.

   If I didn't keep multiple machines, I'd be SOL -- that F8 machine (yes, my #1 
machine; yes, F8 not F9) would be as good as dead: every use I have for a 
computer requires the Net. (I'm on my #2 running F9 now; yes, #2 not #1; yes F9, 
not F8.) 

   Btw, I *hate* running two OSs. Maybe I oughtta declare F9 a total loss in this 
house, and downgrade #2 as well as #1 back to F8 ....

   This is extraordinarily demoralizing to one who has been running RedHat 
products since 7.0 -- it has been getting steadily easier, till F9.
Comment 13 David Cantrell 2008-06-21 15:50:36 EDT
Things do change, and it's just part of the world of Fedora.  NetworkManager brings us a lot of new 
features, but it's difficult for the long time users who have good understandings of the ifcfg script style 
of interface configuration.

F-8 or F-9 don't really matter in this case.  F-9 will most likely work for you, but we need to figure out 
what is actually running for your interface when you boot up.

Questions:
1) Have your installations been upgrades or fresh installs?
2) Can you post the output of "chkconfig --list"?  Just redirect to a file and attach the file to the bug 
report.
3) Can you attach the ifcfg-eth0 file for your system?
Comment 14 Beartooth Bugzapper 2008-06-21 16:32:56 EDT
   This gets ever more mysterious. At the base of the problem, afaict, is the
weird fact that F9 can handle the HP w2207h from #2 machine, but not from #1 --
which is newer, bigger, faster, etc. (What I knkow of hardware would go in a
gnat's eye; a friend builds machines for me.)

   I have tried both upgrades and new install, both of F8 and of F9, both from
behind a KVM switch, and with only #1 connected, directly, to the peripherals.

  Iirc -- big IF -- the latest change was a fresh install of F8, over a
presumably successful but unusable install of F9 (unusable because of the
monitor), with peripherals connected directly.

   Having gotten that to run, and having put it back behind the KVM again, I
proceeded as btth to try to scp all of /home/btth from #2 to #1. Connections
failed. I tried again as root; scp -r (first of /home/btth/* and then of
/home/btth/.*) succeeded.

   Then I did chown -R btth:btth /home/btth/* and chown -R btth:btth
/home/btth/.* (also as root). One of those succeeded; one (.*, iirc) exited
abnormally over some unexpected name.

   Some things failed, presumably over bad dot files; I tried logging out and
back in, then rebooting. Logging out & in fixed most, not all, of it; but Pan
0.132 was still bad (though I do have a .pan2) -- and suddenly, after the
reboot, nothing I do, GUI nor CLI, connects to the net.

  All I can think of is to do "chkconfig --list" on #1; c&p the results, plus
"cat ifcfg-eth0," onto a CD; read the CD in #2; and post it here that way.
 
   I have just logged  into my router (a Netgear MBR 814 provided by my local
ISP); not even its list of attached devices includes the #1 machine. And #1
can't log into it.

   So I think the CD/sneakermail approach is the only feasible one; I can do it,
but it'll take a while.
Comment 15 Beartooth Bugzapper 2008-06-21 17:34:21 EDT
   Here's the data from Machine #1 : 


[root@Tpblk ~]# chkconfig --list
ConsoleKit      0:off   1:off   2:on    3:on    4:on    5:on    6:off
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:on    6:off
NetworkManagerDispatcher        0:off   1:off   2:off   3:off   4:off   5:on   
6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off
avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
btseed          0:off   1:off   2:off   3:off   4:off   5:off   6:off
bttrack         0:off   1:off   2:off   3:off   4:off   5:off   6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off
denyhosts       0:off   1:off   2:off   3:off   4:off   5:on    6:off
firstboot       0:off   1:off   2:off   3:on    4:off   5:on    6:off
fuse            0:off   1:off   2:off   3:on    4:on    5:on    6:off
gpm             0:off   1:off   2:on    3:on    4:on    5:off   6:off
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irda            0:off   1:off   2:off   3:off   4:off   5:off   6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
kudzu           0:off   1:off   2:off   3:on    4:on    5:on    6:off
lm_sensors      0:off   1:off   2:off   3:off   4:off   5:off   6:off
mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
messagebus      0:off   1:off   2:on    3:on    4:on    5:on    6:off
multipathd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
nasd            0:off   1:off   2:off   3:off   4:off   5:on    6:off
netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
netplugd        0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:off   3:off   4:off   5:off   6:off
nfs             0:off   1:off   2:off   3:off   4:off   5:off   6:off
nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off
nscd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
ntpd            0:off   1:off   2:off   3:on    4:off   5:on    6:off
pcscd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
privoxy         0:off   1:off   2:off   3:off   4:off   5:on    6:off
psacct          0:off   1:off   2:off   3:off   4:off   5:off   6:off
rdisc           0:off   1:off   2:off   3:off   4:off   5:off   6:off
restorecond     0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcsvcgssd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
rsyslog         0:off   1:off   2:on    3:on    4:on    5:on    6:off
saslauthd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
scanbuttond     0:off   1:off   2:off   3:off   4:off   5:off   6:off
sendmail        0:off   1:off   2:on    3:on    4:on    5:on    6:off
setroubleshoot  0:off   1:off   2:off   3:on    4:on    5:on    6:off
smartd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
smolt           0:off   1:off   2:on    3:on    4:on    5:on    6:off
snmpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
snmptrapd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:off   2:off   3:on    4:on    5:on    6:off
winbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off
wine            0:off   1:off   2:on    3:on    4:on    5:on    6:off
wpa_supplicant  0:off   1:off   2:off   3:on    4:on    5:on    6:off
xinetd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
ypbind          0:off   1:off   2:off   3:off   4:off   5:off   6:off

xinetd based services:
        chargen-dgram:  off
        chargen-stream: off
        cvs:            off
        daytime-dgram:  off
        daytime-stream: off
        discard-dgram:  off
        discard-stream: off
        echo-dgram:     off
        echo-stream:    off
        rsync:          off
        tcpmux-server:  off
        time-dgram:     off
        time-stream:    off
[root@Tpblk ~]# 

     =====     =====     =====     =====     =====

[root@Tpblk ~]# cd /etc/sysconfig
[root@Tpblk sysconfig]# cd network-scripts
[root@Tpblk network-scripts]# cat ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:18:F3:77:1D:4F
ONBOOT=yes
DHCP_HOSTNAME=Tpblk.localdomain
DNS2=66.37.69.242
TYPE=Ethernet
DNS1=66.37.69.241
#NM_CONTROLLED=no
[root@Tpblk network-scripts]# 


Comment 16 Beartooth Bugzapper 2008-06-22 10:27:26 EDT
   Here's the data from Machine #1 : 


[root@Tpblk ~]# chkconfig --list
ConsoleKit      0:off   1:off   2:on    3:on    4:on    5:on    6:off
NetworkManager  0:off   1:off   2:off   3:off   4:off   5:on    6:off
NetworkManagerDispatcher        0:off   1:off   2:off   3:off   4:off   5:on   
6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
anacron         0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off
avahi-daemon    0:off   1:off   2:off   3:on    4:on    5:on    6:off
btseed          0:off   1:off   2:off   3:off   4:off   5:off   6:off
bttrack         0:off   1:off   2:off   3:off   4:off   5:off   6:off
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off
crond           0:off   1:off   2:on    3:on    4:on    5:on    6:off
cups            0:off   1:off   2:on    3:on    4:on    5:on    6:off
denyhosts       0:off   1:off   2:off   3:off   4:off   5:on    6:off
firstboot       0:off   1:off   2:off   3:on    4:off   5:on    6:off
fuse            0:off   1:off   2:off   3:on    4:on    5:on    6:off
gpm             0:off   1:off   2:on    3:on    4:on    5:off   6:off
haldaemon       0:off   1:off   2:off   3:on    4:on    5:on    6:off
httpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
ip6tables       0:off   1:off   2:on    3:on    4:on    5:on    6:off
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off
irda            0:off   1:off   2:off   3:off   4:off   5:off   6:off
irqbalance      0:off   1:off   2:off   3:on    4:on    5:on    6:off
kudzu           0:off   1:off   2:off   3:on    4:on    5:on    6:off
lm_sensors      0:off   1:off   2:off   3:off   4:off   5:off   6:off
mdmonitor       0:off   1:off   2:on    3:on    4:on    5:on    6:off
messagebus      0:off   1:off   2:on    3:on    4:on    5:on    6:off
multipathd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
nasd            0:off   1:off   2:off   3:off   4:off   5:on    6:off
netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
netplugd        0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:off   3:off   4:off   5:off   6:off
nfs             0:off   1:off   2:off   3:off   4:off   5:off   6:off
nfslock         0:off   1:off   2:off   3:on    4:on    5:on    6:off
nscd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
ntpd            0:off   1:off   2:off   3:on    4:off   5:on    6:off
pcscd           0:off   1:off   2:on    3:on    4:on    5:on    6:off
privoxy         0:off   1:off   2:off   3:off   4:off   5:on    6:off
psacct          0:off   1:off   2:off   3:off   4:off   5:off   6:off
rdisc           0:off   1:off   2:off   3:off   4:off   5:off   6:off
restorecond     0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcbind         0:off   1:off   2:on    3:on    4:on    5:on    6:off
rpcgssd         0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcidmapd       0:off   1:off   2:off   3:on    4:on    5:on    6:off
rpcsvcgssd      0:off   1:off   2:off   3:off   4:off   5:off   6:off
rsyslog         0:off   1:off   2:on    3:on    4:on    5:on    6:off
saslauthd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
scanbuttond     0:off   1:off   2:off   3:off   4:off   5:off   6:off
sendmail        0:off   1:off   2:on    3:on    4:on    5:on    6:off
setroubleshoot  0:off   1:off   2:off   3:on    4:on    5:on    6:off
smartd          0:off   1:off   2:off   3:off   4:off   5:off   6:off
smolt           0:off   1:off   2:on    3:on    4:on    5:on    6:off
snmpd           0:off   1:off   2:off   3:off   4:off   5:off   6:off
snmptrapd       0:off   1:off   2:off   3:off   4:off   5:off   6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:off   2:off   3:on    4:on    5:on    6:off
winbind         0:off   1:off   2:off   3:off   4:off   5:off   6:off
wine            0:off   1:off   2:on    3:on    4:on    5:on    6:off
wpa_supplicant  0:off   1:off   2:off   3:on    4:on    5:on    6:off
xinetd          0:off   1:off   2:off   3:on    4:on    5:on    6:off
ypbind          0:off   1:off   2:off   3:off   4:off   5:off   6:off

xinetd based services:
        chargen-dgram:  off
        chargen-stream: off
        cvs:            off
        daytime-dgram:  off
        daytime-stream: off
        discard-dgram:  off
        discard-stream: off
        echo-dgram:     off
        echo-stream:    off
        rsync:          off
        tcpmux-server:  off
        time-dgram:     off
        time-stream:    off
[root@Tpblk ~]# 

     =====     =====     =====     =====     =====

[root@Tpblk ~]# cd /etc/sysconfig
[root@Tpblk sysconfig]# cd network-scripts
[root@Tpblk network-scripts]# cat ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:18:F3:77:1D:4F
ONBOOT=yes
DHCP_HOSTNAME=Tpblk.localdomain
DNS2=66.37.69.242
TYPE=Ethernet
DNS1=66.37.69.241
#NM_CONTROLLED=no
[root@Tpblk network-scripts]# 


Comment 17 Beartooth Bugzapper 2008-06-22 18:16:18 EDT
   More weirdness. Failing to connect by any method I could find, I logged out 
and in; no joy. Then I put in a live CD of the new openSUSE 11, booted from 
that, played with it a while, established that it connected -- and, for the 
hell of it, started an install, meaning to let it go up to but not past the 
point of commitment. 

    It didn't get there. It was close, past tweaking partitions, and then hit a 
segmentation fault.

   Shrug. So I rebooted again, took the CD out, and let F8 boot.

   It connected during boot. I'm on it now.

   What I do not find, particularly in the man pages, is what to do if 
NetworkManager fails. If not "service network start," what?? 

   usr/bin/system-config-network, according to the properties button, is the 
command in the other icon (like two monitors connected by shiny iron pipes) 
which *sometimes* lets me 'activate' an 'inactive' ethX; but that fails more 
often than not ...
Comment 18 David Cantrell 2008-06-23 10:37:53 EDT
From your reports, it sounds like you possibly have some other problems going on.  What I would suggest 
now is eliminating NetworkManager from the equation and just trying to run dhclient by hand.  If that 
fails, I would say other problems are happening:

# service NetworkManagerDispatcher stop
# service NetworkManager stop
# ifcfg eth0 down
# dhclient eth0

See if that works.
Comment 19 Beartooth Bugzapper 2008-06-23 11:09:44 EDT
   Here it is -- Greek to me ...

[root@Tpblk ~]# service NetworkManagerDispatcher stop
Stopping NetworkManagerDispatcher daemon:                  [  OK  ]
You have new mail in /var/spool/mail/root
[root@Tpblk ~]# service NetworkManager stop
Stopping NetworkManager daemon:                            [  OK  ]
[root@Tpblk ~]# ifcfg eth0 down
/sbin/ifcfg: line 25: [: down: integer expression expected
/sbin/ifcfg: line 26: [: down: integer expression expected
/sbin/ifcfg: line 27: [: down: integer expression expected
/sbin/ifcfg: line 28: [: down: integer expression expected
arping: unknown host down
Error: some host already uses address down on eth0.
[root@Tpblk ~]# dhclient eth0
Internet Systems Consortium DHCP Client V3.0.6-Fedora
Copyright 2004-2007 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/
Listening on LPF/eth0/00:18:f3:77:1d:4f
Sending on   LPF/eth0/00:18:f3:77:1d:4f
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 192.168.0.1
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.0.1
bound to 192.168.0.3 -- renewal in 127937 seconds.
[root@Tpblk ~]# 
Comment 20 David Cantrell 2008-06-23 11:23:32 EDT
(In reply to comment #19)
>    Here it is -- Greek to me ...
> 
> [root@Tpblk ~]# service NetworkManagerDispatcher stop
> Stopping NetworkManagerDispatcher daemon:                  [  OK  ]
> You have new mail in /var/spool/mail/root
> [root@Tpblk ~]# service NetworkManager stop
> Stopping NetworkManager daemon:                            [  OK  ]
> [root@Tpblk ~]# ifcfg eth0 down
> /sbin/ifcfg: line 25: [: down: integer expression expected
> /sbin/ifcfg: line 26: [: down: integer expression expected
> /sbin/ifcfg: line 27: [: down: integer expression expected
> /sbin/ifcfg: line 28: [: down: integer expression expected
> arping: unknown host down

These messages are bad.

> Error: some host already uses address down on eth0.
> [root@Tpblk ~]# dhclient eth0
> Internet Systems Consortium DHCP Client V3.0.6-Fedora
> Copyright 2004-2007 Internet Systems Consortium.
> All rights reserved.
> For info, please visit http://www.isc.org/sw/dhcp/
> Listening on LPF/eth0/00:18:f3:77:1d:4f
> Sending on   LPF/eth0/00:18:f3:77:1d:4f
> Sending on   Socket/fallback
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
> DHCPOFFER from 192.168.0.1
> DHCPREQUEST on eth0 to 255.255.255.255 port 67
> DHCPACK from 192.168.0.1
> bound to 192.168.0.3 -- renewal in 127937 seconds.
> [root@Tpblk ~]# 

You got a lease and the interface is configured at this point.  DHCPACK and "bound to" indicates that.  
You can type ifconfig at this point and see that the interface is configured.

To me, this means that the things that sit on top of dhclient (NetworkManager, for example) are broken 
in some way.  Errors from the /sbin/ifcfg script mean to me that you have a broken installation and you 
need to reinstall and make sure you format the filesystem too.  Note that formatting the filesystem will 
erase everything, so make sure you back up any data you want to keep.
Comment 21 Beartooth Bugzapper 2008-06-23 15:17:36 EDT
> [root@Tpblk ~]# ifcfg eth0 down
> /sbin/ifcfg: line 25: [: down: integer expression expected
> /sbin/ifcfg: line 26: [: down: integer expression expected
> /sbin/ifcfg: line 27: [: down: integer expression expected
> /sbin/ifcfg: line 28: [: down: integer expression expected
> arping: unknown host down

These messages are bad.

     I had a nasty sneakin' hunch they were.

> Listening on LPF/eth0/00:18:f3:77:1d:4f
> Sending on   LPF/eth0/00:18:f3:77:1d:4f
> Sending on   Socket/fallback
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
> DHCPOFFER from 192.168.0.1
> DHCPREQUEST on eth0 to 255.255.255.255 port 67
> DHCPACK from 192.168.0.1
> bound to 192.168.0.3 -- renewal in 127937 seconds.
> [root@Tpblk ~]# 

You got a lease and the interface is configured at this point.  DHCPACK and
"bound to" indicates that.  
You can type ifconfig at this point and see that the interface is configured.

    I did, and it looked blessedly normal -- and the machine is connected.


To me, this means that the things that sit on top of dhclient (NetworkManager,
for example) are broken 
in some way.  Errors from the /sbin/ifcfg script mean to me that you have a
broken installation and you 
need to reinstall and make sure you format the filesystem too.  Note that
formatting the filesystem will 
erase everything, so make sure you back up any data you want to keep.

   OK, let me make sure I have all this straight.

   First of all, the trouble turns out to be something that has gotten into 
this specific machine, and not a bug at all; my apologies for taking your time, 
and profuse thanks for it!

   Second, by "reinstall" I think you mean not just some app or group of apps, 
but the whole nine yards -- *all* of F8 or F9. <whimper, sniff>

   And I suppose an upgrade won't do it, since you mention backing up data. 
<sob, gasp, snimper, whiff> I suspect an upgrade with reformat of filesystem 
(involving qtparted or gparted?) would be an uncertain in-between case. I 
*think* a fresh install automatically includes formatting, right?

  Two things may be relevant here. One, the machine has a second hard drive, 
dual-booting (rarely) to XP to run GPS-interfacing topo map software; I trust 
*not* formatting that shouldn't introduce a hazard. (Fedora is sda, XP sdb.)

   Two, at the advice of someone on fedora.general, I have just done this : 

Transaction Test Succeeded
Running Transaction
  Installing: livna-config-display         ######################### [1/5] 
  Installing: xorg-x11-drv-nvidia-libs     ######################### [2/5] 
  Installing: kmod-nvidia-2.6.25.6-27.fc8  ######################### [3/5] 
  Installing: xorg-x11-drv-nvidia          ######################### [4/5] 
  Installing: kmod-nvidia                  ######################### [5/5] 

Dependency Installed: kmod-nvidia.i686 0:173.14.09-2.lvn8 kmod-
nvidia-2.6.25.6-27.fc8.i686 0:173.14.09-2.lvn8 livna-config-display.noarch 
0:0.0.20-1.lvn8 xorg-x11-drv-nvidia.i386 0:173.14.09-1.lvn8 xorg-x11-drv-nvidia-
libs.i386 0:173.14.09-1.lvn8
Complete!
[root@Tpblk ~]#

   I would of course like to think that might make an upgrade feasible; but I 
don't suppose it does. More likely, I'll want to do it over after the new 
install ...
Comment 22 Beartooth Bugzapper 2008-06-23 16:12:27 EDT
> [root@Tpblk ~]# ifcfg eth0 down
> /sbin/ifcfg: line 25: [: down: integer expression expected
> /sbin/ifcfg: line 26: [: down: integer expression expected
> /sbin/ifcfg: line 27: [: down: integer expression expected
> /sbin/ifcfg: line 28: [: down: integer expression expected
> arping: unknown host down

These messages are bad.

     I had a nasty sneakin' hunch they were.

> Listening on LPF/eth0/00:18:f3:77:1d:4f
> Sending on   LPF/eth0/00:18:f3:77:1d:4f
> Sending on   Socket/fallback
> DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
> DHCPOFFER from 192.168.0.1
> DHCPREQUEST on eth0 to 255.255.255.255 port 67
> DHCPACK from 192.168.0.1
> bound to 192.168.0.3 -- renewal in 127937 seconds.
> [root@Tpblk ~]# 

You got a lease and the interface is configured at this point.  DHCPACK and
"bound to" indicates that.  
You can type ifconfig at this point and see that the interface is configured.

    I did, and it looked blessedly normal -- and the machine is connected.


To me, this means that the things that sit on top of dhclient (NetworkManager,
for example) are broken 
in some way.  Errors from the /sbin/ifcfg script mean to me that you have a
broken installation and you 
need to reinstall and make sure you format the filesystem too.  Note that
formatting the filesystem will 
erase everything, so make sure you back up any data you want to keep.

   OK, let me make sure I have all this straight.

   First of all, the trouble turns out to be something that has gotten into 
this specific machine, and not a bug at all; my apologies for taking your time, 
and profuse thanks for it!

   Second, by "reinstall" I think you mean not just some app or group of apps, 
but the whole nine yards -- *all* of F8 or F9. <whimper, sniff>

   And I suppose an upgrade won't do it, since you mention backing up data. 
<sob, gasp, snimper, whiff> I suspect an upgrade with reformat of filesystem 
(involving qtparted or gparted?) would be an uncertain in-between case. I 
*think* a fresh install automatically includes formatting, right?

  Two things may be relevant here. One, the machine has a second hard drive, 
dual-booting (rarely) to XP to run GPS-interfacing topo map software; I trust 
*not* formatting that shouldn't introduce a hazard. (Fedora is sda, XP sdb.)

   Two, at the advice of someone on fedora.general, I have just done this : 

Transaction Test Succeeded
Running Transaction
  Installing: livna-config-display         ######################### [1/5] 
  Installing: xorg-x11-drv-nvidia-libs     ######################### [2/5] 
  Installing: kmod-nvidia-2.6.25.6-27.fc8  ######################### [3/5] 
  Installing: xorg-x11-drv-nvidia          ######################### [4/5] 
  Installing: kmod-nvidia                  ######################### [5/5] 

Dependency Installed: kmod-nvidia.i686 0:173.14.09-2.lvn8 kmod-
nvidia-2.6.25.6-27.fc8.i686 0:173.14.09-2.lvn8 livna-config-display.noarch 
0:0.0.20-1.lvn8 xorg-x11-drv-nvidia.i386 0:173.14.09-1.lvn8 xorg-x11-drv-nvidia-
libs.i386 0:173.14.09-1.lvn8
Complete!
[root@Tpblk ~]#

   I would of course like to think that might make an upgrade feasible; but I 
don't suppose it does. More likely, I'll want to do it over after the new 
install ...
Comment 23 David Cantrell 2008-06-24 09:49:16 EDT
(In reply to comment #22)
> > [root@Tpblk ~]# ifcfg eth0 down
> > /sbin/ifcfg: line 25: [: down: integer expression expected
> > /sbin/ifcfg: line 26: [: down: integer expression expected
> > /sbin/ifcfg: line 27: [: down: integer expression expected
> > /sbin/ifcfg: line 28: [: down: integer expression expected
> > arping: unknown host down
> 
> These messages are bad.
> 
>      I had a nasty sneakin' hunch they were.
> 
> > Listening on LPF/eth0/00:18:f3:77:1d:4f
> > Sending on   LPF/eth0/00:18:f3:77:1d:4f
> > Sending on   Socket/fallback
> > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
> > DHCPOFFER from 192.168.0.1
> > DHCPREQUEST on eth0 to 255.255.255.255 port 67
> > DHCPACK from 192.168.0.1
> > bound to 192.168.0.3 -- renewal in 127937 seconds.
> > [root@Tpblk ~]# 
> 
> You got a lease and the interface is configured at this point.  DHCPACK and
> "bound to" indicates that.  
> You can type ifconfig at this point and see that the interface is configured.
> 
>     I did, and it looked blessedly normal -- and the machine is connected.

That's good, actually.  That means your hardware is working correctly, so the problems here are with 
the software on top of dhclient.

> To me, this means that the things that sit on top of dhclient (NetworkManager,
> for example) are broken 
> in some way.  Errors from the /sbin/ifcfg script mean to me that you have a
> broken installation and you 
> need to reinstall and make sure you format the filesystem too.  Note that
> formatting the filesystem will 
> erase everything, so make sure you back up any data you want to keep.
> 
>    OK, let me make sure I have all this straight.
> 
>    First of all, the trouble turns out to be something that has gotten into 
> this specific machine, and not a bug at all; my apologies for taking your time, 
> and profuse thanks for it!

No problem, that's what we're here to do.  Open source software isn't just about making lots of 
packages available to people.  We also try to help people _use_ the software.  :)

>    Second, by "reinstall" I think you mean not just some app or group of apps, 
> but the whole nine yards -- *all* of F8 or F9. <whimper, sniff>

Yes, complete format and reinstall from the beginning.  To me, it's not scary.  I work on anaconda too, 
so I do hundreds of installs each day.  :)

>    And I suppose an upgrade won't do it, since you mention backing up data. 
> <sob, gasp, snimper, whiff> I suspect an upgrade with reformat of filesystem 
> (involving qtparted or gparted?) would be an uncertain in-between case. I 
> *think* a fresh install automatically includes formatting, right?

Anaconda will find your existing installation and offer to either upgrade or install fresh.  You want to 
install fresh and let it format the filesystems.

>   Two things may be relevant here. One, the machine has a second hard drive, 
> dual-booting (rarely) to XP to run GPS-interfacing topo map software; I trust 
> *not* formatting that shouldn't introduce a hazard. (Fedora is sda, XP sdb.)

During the installation, you will be presented with a list of hard disks the install found.  If Windows is 
the entire sdb disk, you can uncheck it in the installer and anaconda will completely ignore that disk 
during installation.

>    Two, at the advice of someone on fedora.general, I have just done this : 
> 
> Transaction Test Succeeded
> Running Transaction
>   Installing: livna-config-display         ######################### [1/5] 
>   Installing: xorg-x11-drv-nvidia-libs     ######################### [2/5] 
>   Installing: kmod-nvidia-2.6.25.6-27.fc8  ######################### [3/5] 
>   Installing: xorg-x11-drv-nvidia          ######################### [4/5] 
>   Installing: kmod-nvidia                  ######################### [5/5] 
> 
> Dependency Installed: kmod-nvidia.i686 0:173.14.09-2.lvn8 kmod-
> nvidia-2.6.25.6-27.fc8.i686 0:173.14.09-2.lvn8 livna-config-display.noarch 
> 0:0.0.20-1.lvn8 xorg-x11-drv-nvidia.i386 0:173.14.09-1.lvn8 xorg-x11-drv-nvidia-
> libs.i386 0:173.14.09-1.lvn8
> Complete!
> [root@Tpblk ~]#
> 
>    I would of course like to think that might make an upgrade feasible; but I 
> don't suppose it does. More likely, I'll want to do it over after the new 
> install ...

Adding 3rd party repositories to your configuration is possible during installation, but I would 
recommend doing it after the main installation.

Since this is an bad installation and not a problem with dhcp, I'm going to go ahead and close the bug.  
If you have general installation questions, feel free to jump in #fedora and ask there or you can email 
me directly (dcantrell@redhat.com).

Last but not least, PLEASE back up any data you care about.  I've never seen an installation of Fedora eat 
data, but backups are just good practice anyway.

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