Bug 449120
| Summary: | dhclient fails to restart for 'service network restart' | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Beartooth Bugzapper <karhunhammas> | ||||||
| Component: | dhcp | Assignee: | David Cantrell <dcantrell> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 9 | CC: | cra, frankly3d | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-06-24 13:49:16 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: | |||||||||
| Attachments: |
|
||||||||
|
Description
Beartooth Bugzapper
2008-05-30 15:45:06 UTC
Created attachment 307209 [details]
came up when I ssh'd into a LAN machine after a connection outage
Interesting...will have to see if I can recreate that here and figure it out.
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.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.]
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. 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 ~]#
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
dhclient-4.0.0-14.fc9.i386 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
Changing to version 9.
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.
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. 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. 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? 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.
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]#
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]#
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 ...
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. 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 ~]# (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. > [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 ... > [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 ... (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). 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. |