This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1162822
When ifup is called on an interface that has BOOTPROTO=dhcp, ifup-eth
will call network-functions:check_link_down() to wait for carrier on
the interface before starting dhclient. If the interface happens to be
a bridge device, carrier will not come on until at least one attached
device is in "forwarding" mode. If the bridge has STP enabled, it
takes at least $DELAY * 2 + 5 seconds (sometimes slightly longer) for
any attached device to go into forwarding mode.
However, check_link_down() will only wait for max(${LINKDELAY}, 5)
seconds for carrier, and there are *many* existing configs that have
STP enabled but no setting for LINKDELAY. Every one of those configs
will now fail to ifup the bridge device.
The solution implemented in this patch is for ifup-eth to set
LINKDELAY to at least ${DELAY} * 2 + 7 when the device is a bridge an
STP is enabled. Since check_link_down() returns within .5 sec of
carrier coming up, the worst effect this could have would be to take
longer to fail in the case of a config where carrier was *never* going
to come up. Otherwise, it will not create any more delay than is
already present in cases that currently work, and will cause many
other configs to become unbroken.