Created attachment 400439 [details] proposed patch Description of problem: I have a bridge interface which I use to share the connection with the virt-manager guest. On my environment, the bridge only contains the eth0 interface. IP Address gathering is done through dhcp. Every time I change the environment (eth0 is not physically connected - I'm using the wireless interface) the ifup-eth <bridge_interface> takes up to 2 minutes to fail. This sheds a dark light on all the efforts to improve the boot time. The problem seems to be in the way Fedora/Redhat checks for link status. In the check_link_down() network function, the ethtool utility will _always_ see the link status as up for the bridged interface. As a consequence, when determining the IP information for the bridge interface, the script will fall into the last else statement (line 220) and dhclient will vainly try to configure the interface. This issue can be fixed in different ways, I've chosen the one that best suits my needs: I've created a patch that adds additional link status checking for bridge interfaces: - if the link is detected, extract the interface(s) from the bridge and run check_ethtool() on that/(those?) interface(s). If this/(these?) interface(s) is physically down then return 0, else go through the normal cycle. Note that my patch only checks for the first component from the bridge. I'm pretty sure that this can be reproducible on all the Fedora/RedHat versions. Version-Release number of selected component (if applicable): initscripts-9.02.1-1.i686 ethtool-6-7.20090323git.fc12.i686 brctl show bridge name bridge id STP enabled interfaces vbridge 8000.001a4b79xxx no eth0 ethtool vbridge Settings for vbridge: Link detected: yes cat /etc/sysconfig/network-scripts/ifcfg-vbridge DEVICE=vbridge TYPE=Bridge BOOTPROTO=dhcp ONBOOT=yes NM_CONTROLLED=no USERCTL=no IPV6INIT=no cat /etc/sysconfig/network-scripts/ifcfg-eth0 DEVICE=eth0 BRIDGE=vbridge ONBOOT=yes NM_CONTROLLED=no NEEDHOSTNAME=yes cat /var/lib/dhclient/dhclient-vbridge.leases lease { interface "vbridge"; fixed-address xxx; option subnet-mask 255.255.254.0; option routers xxx; option dhcp-lease-time 1296000; option dhcp-message-type 5; option domain-name-servers xxx; option dhcp-server-identifier xxx; option dhcp-renewal-time 648000; option dhcp-rebinding-time 1134000; option domain-name "xxx"; renew 1 2010/03/22 01:35:01; rebind 0 2010/03/28 11:22:24; expire 2 2010/03/30 08:22:24; } uname -a Linux chronic 2.6.32.9-70.fc12.i686.PAE #1 SMP Wed Mar 3 04:57:21 UTC 2010 i686 i686 i386 GNU/Linux How reproducible: Steps to Reproduce: 1. at boot-time, remove the physical link from the ethernet card 2. ifup-eth tries to bring up the vbridge interface even though there's no link present Actual results: The script fails after ~2min Expected results: The script should fail with the "failed; no link present. Check cable?" warning message, this takes ~10 seconds => improved boot-time. Additional info: Attaching patch.
I'm curious, what happens if you manually apply http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=a21eb994804e40f920d0e83afd2a4ec9b8c60c33 ? Does that improve things? (Given what you state about ethtool, I'm guessing it may not, but that's where I'd like to start.)
That approach won't work because the bridge interface will return 1 even in the carrier is down. With the cable unplugged scenario we have: cat /sys/class/net/vbridge/carrier cat: /sys/class/net/vbridge/carrier: Invalid argument -then we try bringing the interface up: ip link set dev vbridge up -even though the interface is still down we'll have: cat /sys/class/net/vbridge/carrier 1 -we're back where we started => dhclient will try to assing an IP address. This could be a better approach: -when we try bringing up the interface, if the physical link is down, the following command will output a DOWN/UNKNOWN (for bridge interfaces) state so we could test on this. ip link show dev vbridge 4: vbridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether xx:xx:xx:xx:14:60 brd ff:ff:ff:ff:ff:ff Attaching an updated patch: - it tests for the ",UP" state (I guess that the comma was probably added to solve another issue?) - added an additional test for the UP/DOWN/any_other_value state for the same output - there's no need to use ethtool ------- time /etc/sysconfig/network-scripts/ifup-eth vbridge Determining IP information for vbridge... failed; no link present. Check cable? real 0m5.673s user 0m0.065s sys 0m0.123s
Created attachment 400613 [details] proposed patch - updated version
Note that the link_state value from <BROADCAST,MULTICAST,UP,LOWER_UP> is not correct. Probably that's where /sys/class/net/vbridge/carrier and ethtool get their bogus data from.
Disregard the last patch it doesn't work as expected. Instead the newest patch does work by using the following plan of though: - this is the initial output for the vbridge interface: ip link show dev vbridge 4: vbridge: <BROADCAST,MULTICAST,LOWER_UP> mtu 1500 qdisc noqueue state DOWN link/ether 00:1a:4b:79:14:60 brd ff:ff:ff:ff:ff:ff - after that we verify if we're dealing with a bridged interface, if yes, we extract all the interfaces contained in the bridge: ls /sys/class/net/vbridge/brif/ eth0 (eth1 eth2 ...) - if we can't find the comma separated UP statement (<,UP>) for these interfaces, we bring up the links: ip link set dev eth0 up - after that we verify the actual state and whether the link becomes active _for every interface_ in a 10 seconds loop ip link show dev eth0 | grep "state UP" eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 (we could have UP/DOWN or UNKNOWN) - else (if we didn't find a bridged interface) we try the original script for normal interfaces.
Created attachment 400743 [details] proposed patch
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping