Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, May 30, 2011 at 09:51:15AM +0200, Felix Frank wrote: > > Does "X-Start-Before" mean start this before these, or start these before > > this? Ubuntu as a Debian should obey this LSB stuff. But > > Careful - you're agitating the Debian crowd ;-) > > I wouldn't be so quick to assume that Ubuntu does these things in the > exact Debian way. Sure, wouldn't be surprised if it's Ubuntu breakage. My question is real though. Does "X-Start-Before" mean "start before," so that DRBD's init.d file is insisting it be started before heartbeat? Or does the "X" negate the meaning, so that "X-Start-Before" means start after? On the one hand, yes heartbeat should start DRBD; I did this wrong even having DRBD's init.d script active. On the other, if both are being started, heartbeat should start first, in which case if heartbeat starts DRBD it will get that done ... and the DRBD init.d, if triggered, will just fail since it's already started. > > # Required-Start: $local_fs $network $syslog > > > > which pretty clearly should be telling the system not to start drbd before > > the network is up. But it's trying anyway. Although that Debian page says: > It all depends on the way you're booting. A concurrent boot will honour > this. A symlink that was put into /etc/rcX.d by update-rc.d (or insserv) > should have been OK, too. Of course, if someone messed with the start > order, that's bunk now. Nobody's messed with the start order. So it may be Ubuntu upstart breakage. > I don't see the big problem. You have a KVM connected? Why don't you > boot into runlevel 1 and put DRBD late in the boot order? (Please tell > me you can power down from remote.) Okay, I can cycle power from remote all I like. The problem is the SuperMicro IPMI has Java Web applets for SOL - which handles the BIOS end of the thing, and for Console Redirection - which presents the boot process ... BUT ... the boot process as shown through Console Redirection shows up a bit late in that process visually, and apparently the keyboard isn't active either until then (I've tried, repeatedly), so there's no effective way to get grub to boot into anything else. A fix would be to add the necessary flags to the kernel's grub listing so that SOL will remain working as the kernel takes over. Obviously I hadn't done that here. So using the FreeIPMI SOL viewer doesn't get me there either. > Also, what would (in your eyes) be wrong about configuring a wait > timeout and then just leave DRBD "running"? It sure won't break anything. Sure, I should configure a wait timeout. But what's wrong in my tired eyes is drbdadmin, when called from an init.d script at least, by default running forever waiting for the connection. As we see here, in some situations that init.d script can run before networking is up, so it hangs forever. What would be wrong with the default behavior being to run for, say, ten minutes waiting, and then give up? Because by continuing to run then it's broken something. Giving up, with appropriate messaging, there's still something broken, but it's smaller than the whole system being hung. Another thing that's odd in this situation is that the keyboard is fully working in SOL, and appears to be working in Console Redirection too, yet I can't get a 'yes' through to drbdadmin. I can get a CR through to it, just not 'yes'. Weird. So it looks like I'll be heading in tomorrow ... 4 hours travel each way. Best, Whit