Bug 288361

Use the LINKDELAY parameter, as documented in sysconfig.txt:

    LINKDELAY=<time in seconds>
      Time that the system should pause after the specific interface is
      enabled.  This may be useful if one interface is connected to a
      switch which has spanning tree enabled and must wait for STP to
      converge before the interface should be considered usable.

What you offer will allow me to address this issue through configuration however it doesn't help the 
average user out their that has this configuration to understand what is wrong.

This configuration is perfectly acceptable and nothing is wrong with the link or cable.

Because FC7 would not boot up on its own I had to spend a significant amount of time investigating 
why this configuration was not working.

If Fedora is interested in producing a reliable user friendly configuration it seems to me like making the 
default delay workable in reasonable cases would be a very good thing for the platform.

I can't see any serious negative to increasing the default delay but I can see a lot of benefit for any 
configuration that has a auto-negotiate delay longer than 5 seconds. 

From my experience this was very frustrating I have a config that worked fine through a network fresh 
install of fc7 yet when I first reboot the system I start getting this error and have to trouble shoot why 
it is happening when the install had no problems loading the OS ever the network.

It is reasonable for the vast majority of our users - we're optimizing for the
common case. (In fact, for nearly all of our users it could be *shorter*.)

Changing the delay on boot to 40 seconds per interface for << 1% of the userbase
isn't really an optimal tradeoff.

I'm sure you do recognize that 99% of your user base as you identify will never experience the 40 
seconds or even the 5 sec delay because the link will get correctly detected sooner and the loop exited 
as soon that is the case.

What you are doing is simply allowing another valid configuration to work for 1% of your users. Sounds 
like a good thing to me. Especially when we are talking about millions of users 1% is still a very large 
number of folks.

Even if you really still feel that adding a delay that has no impact what so ever to 99% of your 
population is a bad thing to help out 1%. It seems to me like improving on the error message to indicate 
that this may simple be an  issue of increasing a delay rather than a cable or link problem would be 
very helpful and informative.

Any time that 99% has a link unplugged, they'll experience that delay.

1% isn't a full number, but considering:

- the number of reports that I get on needing to increase the delay (single digits)
- the number of complaints about the delay (many many)

it's not that far off. Moreover, those that have the issue with it being too
short are invariably those with large enterprise deployments and complicated
switch topologies - those *most able* to edit the configuration files and change
the parameters.

It is clear you understand the issue but have a different opinion on it which is perfectly reasonable.

If Fedora doesn't want to support valid network configurations out of the box (for what ever reason) 
that is Fedora's call.

From my view I could have been saved time if I wasn't sent searching for something that was not the 
issue.

From my view of this specific case a couple things could have helped me:

1) Better error messages that reflected the known issues.
2) If ethtool or mii-tool can report on a card that is in autonegotiate vs no link then perhaps better 
scripts could be developed to be more responsive to the real situation.

Thank you for considering my suggestion if Fedora still feels the best answer for this issue is to simply 
close it go ahead I will leave it alone.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'.

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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

I would like to urge you to reopen this bug, and fix it. Despite it being closed NOTABUG, it *is* a bug.

For the vast majority of today's users, a network *is* available, and giving up after 5 seconds is non-sensical. Worse, the message you show is:

"Determining IP information for eth0... failed; no link present.  Check cable?"

Which gives two confusing, false leads - the first part leads the user to assume the problem is somehow related to DHCP, while the second part leads the user to check the cable. The user can wiggle the cable and "service network restart" till hell freezes over, and it won't help until he increases LINKDELAY.

Since this is a relatively common problem (see also bug 425877 and bug 470327. It also happens frequently in my company's network), shouldn't be the *minimal* fix to this bug to add a short reference to LINKDELAY in the above message?

Frankly, I'm not sure why you are worried about increasing the default LINKDELAY from 5 to something higher, say 10 or 20. Users that don't have no network setup at all will not experience this delay. Users with a functional network will not experience this delay (the loop stops as soon as the link comes up). The only people who will experience the longer delay are people who have set up the network (so they want it up) but their network link is indeed down. The extra delay of 20 seconds is probably the least of their worries in this case. And don't forget to balance this with all the people for whom Fedora will just give up after 5 seconds and never connect to the Internet - while Windows, Ubuntu, and others will not give up so quickly and eventually (say, after 6 seconds ;-)) connect.