Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20050104 Red Hat/1.4.3-3.0.7 Description of problem: When mii-tool is correctly able to determine the link status of an interface, all is well: when the link is ok, dhclient is started, when link is not ok, [failed] is shown. However, when mii-tool is not able to determine the link status (because either mii-tool does not support the network adapter, or because the network adapter does not support this), the scripts automatically assume that there's no link and will not start dhclient. This is particularly annoying for me because the emulated ethernet adapter in VMWare (when running RHEL3 as guest OS) has not implemented link state checking functionality (link is always on, after all). Version-Release number of selected component (if applicable): initscripts-7.31.18.EL-1 How reproducible: Always Steps to Reproduce: 1. Install RHEL3 under VMWare with DHCP 2. Reboot 3. Actual Results: Does not get an IP address, does not start dhclient Expected Results: Should get an IP address Additional info: Simple fix, but a little more scripting might be required for production use: File /etc/sysconfig/network-scripts/network-functions: Line 237-238 now reads: echo $output | LC_ALL=C grep -q "link ok" && return 1 echo $output | LC_ALL=C grep -q "no link" && return 0 || return 2 Change this to: echo $output | LC_ALL=C grep -q "link ok" && return 1 echo $output | LC_ALL=C grep -q "no link" && return 0 || return 1 and all is well.
Your change means 'assume the link is up in case mii-tool fails to determine link status one way or another'. This is a change of behavior and is actually incorrect. The current algorithm: - returns link up if *either* mii-tool or ethtool report link up - returns link up if *both* mii-tool and ethtool report that they're unable to check What your change will do will cause it to return the link as up, if, for example, ethtool claims 'link down' and mii-tool claims "I don't know". That's not correct.
Somehow behaviour was only present when using the original RHEL3, unupdated. An update somewhere along the line has fixed this. I should have tested this on an updated system. Sorry for wasting everybodies time.