[DRBD-user] WFReportParams/WFConnection following reboot of secondary node

Lars Ellenberg lars.ellenberg at linbit.com
Thu Feb 19 12:53:05 CET 2015

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Fri, Feb 06, 2015 at 12:14:37PM +0000, john at atandaconsultancy.co.uk wrote:
> Hi,
> We have a test DRBD setup running in active/passive. Node1 is the
> primary and node2 is the secondary. Yesterday, we rebooted node2 and
> now we have a status of WFReportParams/WFConnection showing on the
> primary and secondary respectively. Can we recover from this? Any
> help would be much appreciated - We don't have any in-house DRBD
> expertise.
> I'm guessing we should have run something like "drbdadm down all" on
> the secondary before rebooting? I've included output below that
> should give more detail about the setup and current state
> # lsb_release -a
> LSB Version: core-2.0-noarch:core-3.0-noarch:core-2.0-x86_64:core-3.0-x86_64:desktop-3.1-amd64:desktop-3.1-noarch:graphics-2.0-amd64:graphics-2.0-noarch:graphics-3.1-amd64:graphics-3.1-noarch
> Distributor ID: SUSE LINUX
> Description:    SUSE Linux Enterprise Server 10 (x86_64)

Sles 10 is end of life.

> primary
> =======
> # cat /proc/drbd
> version: 0.7.22 (api:79/proto:74)

DRBD 0.7 was end of life long ago.

Any bugs or misbehaviour you find, you keep.

> SVN Revision: 2572 build by lmb at dale, 2006-10-25 18:17:21
> 0: cs:WFReportParams st:Primary/Unknown ld:Consistent
>     ns:213178037 nr:3271238 dw:216623891 dr:243061160 al:940678
> bm:2910 lo:0 pe:0 ua:0 ap:0
> secondary
> =========
> # cat /proc/drbd
> version: 0.7.22 (api:79/proto:74)
> SVN Revision: 2572 build by lmb at dale, 2006-10-25 18:17:21
> 0: cs:WFConnection st:Secondary/Unknown ld:Consistent
>     ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0

May be a network glitch, MTU mismatch, or bug in DRBD.

If DRBD "on-board" means do not suffice or block themselves,
you can always try to get DRBD out of whatever network problem it thinks
it is in by REJECTing its ports in and out with iptables...
(and then remove those reject rules again, of course).

Then try again.

Unless DRBD is deadlocked internally somewhere else,
in which case the only way out would be to reboot.

: Lars Ellenberg
: http://www.LINBIT.com | Your Way to High Availability
: DRBD, Linux-HA  and  Pacemaker support and consulting

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
please don't Cc me, but send to list   --   I'm subscribed

More information about the drbd-user mailing list