Bug 462162 - network device won't start at boot
network device won't start at boot
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-13 02:12 EDT by Sean Middleditch
Modified: 2014-03-16 23:15 EDT (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Sean Middleditch 2008-09-13 02:12:24 EDT
My network device (which for some reason comes up as eth1, never eth0) will not activate during boot.  The driver module is loaded and ifconfig eth1 will show the basic data, but the device is just unconfigured.  Oddly, if I run /etc/init.d/network start after the machine is booted up all the way, it configures eth1 fine.  NetworkManager is not used (or even installed).

This happened after I changed the mobo/CPU from my old Athlon 64 X2 to a Phenom X4 on a 780G-based motherboard.  I thought it was some dumb configuration issue (and still suspect it could be), but I'm at wit's end trying to figure this out.  Everything looks right, and I can't find any reason why it wouldn't work.  It's hard for me to debug since the network startup script just works after bootup is complete.

I've tried moving ifcfg-eth1 to ifcfg-eth0, with the thought that perhaps the HWADDR setting is forcing it to become eth1 or otherwise screwing things up, but no dice.  It just doesn't want to come up at boot.

initscripts-8.82-1.x86_64
kernel-2.6.27-0.323.rc6.fc10.x86_64
udev-127-1.fc10.x86_64
hal-0.5.11-4.fc10.x86_64

elanthis@localhost:~$ cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
BOOTPROTO=dhcp
HWADDR=00:19:66:77:EE:B1
ONBOOT=yes
NM_CONTROLLED=
MTU=1492

elanthis@localhost:~$ /sbin/lspci 
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
00:01.0 PCI bridge: ASRock Incorporation Device 9602
00:09.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 4)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 5)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [IDE mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:12.1 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI1 Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:13.1 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI1 Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3a)
00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 10h [Opteron, Athlon64, Sempron] Link Control
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3200 Graphics
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02)
05:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev c0)

I'd post some more info, but gnome-session's DEBUG crap is spamming the hell out of /var/log/messages and some hub message from the latest kernel has spammed dmesg into oblivion.  What I can find with some searching:

(network controller is detected and initialized... but note that it says eth0)
Sep 13 01:27:50 localhost kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loade
d
Sep 13 01:27:50 localhost kernel: r8169 0000:04:00.0: PCI INT A -> GSI 18 (level
, low) -> IRQ 18
Sep 13 01:27:50 localhost kernel: r8169 0000:04:00.0: no MSI. Back to INTx.
Sep 13 01:27:50 localhost kernel: eth0: RTL8168c/8111c at 0xffffc20000670000, 00
:19:66:77:ee:b1, XID 3c2000c0 IRQ 18

(udev renames eth0 to eth1...)
Sep 13 01:27:50 localhost kernel: udev: renamed network interface eth0 to eth1

(I run /etc/init.d/network start after logging in)
Sep 13 01:32:33 localhost kernel: r8169: eth1: link up
Sep 13 01:32:33 localhost kernel: r8169: eth1: link up
Sep 13 01:32:34 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Sep 13 01:32:34 localhost dhclient: DHCPACK from 192.168.1.1
Sep 13 01:32:34 localhost avahi-daemon[2592]: Joining mDNS multicast group on in
terface eth1.IPv4 with address 192.168.1.100.
Sep 13 01:32:34 localhost avahi-daemon[2592]: New relevant interface eth1.IPv4 f
or mDNS.
Sep 13 01:32:34 localhost avahi-daemon[2592]: Registering new address record for
 192.168.1.100 on eth1.IPv4.
Sep 13 01:32:34 localhost NET[3458]: /sbin/dhclient-script : updated /etc/resolv
.conf
Sep 13 01:32:34 localhost dhclient: bound to 192.168.1.100 -- renewal in 32738 s
econds.
Sep 13 01:32:35 localhost dnsmasq[2674]: reading /etc/resolv.conf
Sep 13 01:32:35 localhost dnsmasq[2674]: using nameserver 68.94.157.1#53
Sep 13 01:32:35 localhost dnsmasq[2674]: using nameserver 68.94.156.1#53
Sep 13 01:32:35 localhost avahi-daemon[2592]: Registering new address record for
 fe80::219:66ff:fe77:eeb1 on eth1.*.
Comment 1 Sean Middleditch 2008-09-13 03:02:48 EDT
Fun part of the story for anyone finding this bug via search engines and wondering about the device naming bit:

However, I got the device to show up as eth0.  After digging around in the udev and initscript sources I found the rename_device utility and its sources, found what it was doing, and fixed the error.  I guess the HWADDR in the ifcfg-* files must be lower-cased to match the output of /sys/class/net/eth*/address.  Fixed that.  Also found the /etc/udev/rules.d/70-persistent-net.rules file, which I deleted and let get regenerated on next boot.


Amuzing part of the story for people to learn from:

chkconfig --list network
network        	0:off	1:off	2:off	3:off	4:off	5:off	6:off

I don't know how the hell that get set like that, but it's fixed now.

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