Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Sat, May 28, 2011 at 04:25:45PM -0400, Dan Barker wrote: > The setting is wfc-timeout and possibly degr-wfc-timeout. Unless you can > force power off the machine and mount it's boot disk (like you would be able > to in a VM setting), I think you have to drive over there or talk the > janitor into typing YES. Trying to figure out why it won't take 'yes' remotely. It'll take Return. It'll take function keys to bounce between terminal sessions. It just can't get drbd to recognize 'yes.' Somehow I've ended up running an init.d script for drbd that's dumb enough to try to start drbd before networking is up. So there's no chance at all that the connection it's waiting for with the second system will ever be seen. There would seem to be a third option in these situations. Right now it's either "start drbd and wait for the connection for X minutes before proceeding" or "start drbd and wait forever before proceeding." Both of those simply leave drbd running. What would be useful is a default of "start drbd, wait for X minutes for the connection (with a default of, say, 10 minutes) after which _stop drbd_, issue a warning about that, and proceed with the OS boot." That would be the best of both worlds. You never get drbd starting in a bad state, because it shuts itself down after X minutes if a good state isn't established. And you never get a remote system that refused to finish booting because drbd is sitting there unhappy. Whit