Hi,<br><br>It seems there is a bug in the parsing of the value of the `shared-secret&#39; parameter : if the shared-secret starts with a numerical character, it will make &quot;drbdadm adjust&quot; fail on any later adjustment with the error message : &quot;&lt;shared_secret_value&gt; it not a valid number&quot;.
<br><br>I have an OpenFiler cluster running DRBD 8.0.2, and another cluster running 8.0.4.<br><br>I initially configured their shared-secret value with the output of `/proc/sys/kernelk/random/uuid&#39;. Now, whenever I do a &quot;drbdadm adjust all&quot; it complains that my shared-secret value &quot;is not a valid number&quot; :
<br><br># drbdadm adjust all<br>35a8e289b8f02a315e1fa4827ec0e83f is not a valid number<br><br>Here is the corresponding net {} section :<br><br>net {<br>&nbsp;&nbsp;&nbsp; cram-hmac-alg &quot;sha1&quot;;<br>&nbsp;&nbsp;&nbsp; shared-secret &quot;35a8e289b8f02a315e1fa4827ec0e83f&quot;;
<br>&nbsp;&nbsp;&nbsp; after-sb-0pri disconnect;<br>&nbsp;&nbsp;&nbsp; after-sb-1pri disconnect;<br>&nbsp;&nbsp;&nbsp; after-sb-2pri disconnect;<br>&nbsp;&nbsp;&nbsp; rr-conflict disconnect;<br>}<br><br>I changed the shared-secret to something shorter (e.g. &quot;foo&quot;), rebooted the machine, and after trying longer strings without error, I finally reverted to my original UUID strings but changed the first character from `3[...]&#39; to `a[...]&#39; and now the drbdadm adjust does not complains that the value is not a valid number.
<br><br>So, it seems that if you set your shared-secret value with a string that begins with a number, then any subsequent drbdadm adjust will fail, leaving you with the only solution of rebooting the machine to take new parameters (even a new shared-secret) into account.
<br><br>Regards,<br>Jérôme Augé<br>