On 10/08/2010 03:59 PM, PÃdraig Brady wrote:
On 08/10/10 14:30, Seewer Philippe wrote:
On 10/08/2010 12:20 PM, PÃdraig Brady wrote:
My terminals just failed to boot because the router
was (temporarily) unavailable. Seems this is on purpose?
http://dracut.git.sourceforge.net/git/gitweb.cgi?p=dracut/dracut;a=commit;h=98f25e96
I don't know what the above is trying to do exactly.
What this does ist simply try and give a possible router enough time to
update its STP caches (See
http://en.wikipedia.org/wiki/Spanning_tree_protocol) so that subsequent
mount attempts don't fail because the router isn't ready.
So yes, it is on purpose if the available IP information contains routers.
I Hope this helps
Thanks for the info, but.
Is it right to do this synchronously with such a long timeout?
It has to be done synchronously, sorry. We have to be sure the router is
there and ready if the rootserver is behind the router.
As for the timeout: STP can take between 30-60 seconds. (There's a
reason why there's newer protocols like RSTP etc).
Is it right to die if we can't contact the router?
Usually yes. Either because the rootserver is behind the router or if
you supplied routing information it's safe to assume that later you want
it to work anyway.
But yes, usually. I would have preferred to somehow a subnet check on
the rootserver to decide what or if to check. But alas, not all netroot
variants know the ip of their rootserver at that point.
I'm always open for ideas on how to improve this.
Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
