© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
Finally figured out the problem with LCMC which maybe also improves other drbdsetup oddness. The problem is that unlike drbdadm, drbdsetup did not use the kernel drbd module version to decide whether it should run the legacy binary. Instead it waited for some socket connection to fail. But that happened relatively late and so at least the xml help would only be processed by the main command. And of course the arguments for that have been changed by upstream as well (help-xml instead of xml).
I added some code to additionally check /proc/drbd and in case of a module version < 8.4.0 run the legacy drbdsetup immediately. So far this allowed to use LCMC to define a new drbd resource and selecting migrate for the resource would display it as migrated instead of "exploding".
This should also be tested after installing a later kernel. But if the version as it is now unbreaks at least the users of 3.2 kernels its probably best to go with that and make fixes to the lts-kernel case later on top. Better than breaking current installs.