[DRBD-user] "To resolve this both sides have to support at least protocol" after upgrade

Tim Sharpe tim at sharpe.id.au
Wed Dec 8 02:37:07 CET 2010

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

Hi all,

I was upgrading one of our older DRBD pairs from 8.3.2 to 8.3.7 today
and ran into a bit of a problem.  I took the resources on the
secondary down, upgraded the kernel & DRBD, rebooted and brought the
resources back up again.  One of the resources on the secondary
refused to reconnect to the primary server however the other 15
connected and resynced fine.

Here's the log for the resource
block drbd12: Starting worker thread (from cqueue [4198])
block drbd12: disk( Diskless -> Attaching )
block drbd12: Found 34 transactions (2033 active extents) in activity log.
block drbd12: Method to ensure write ordering: barrier
block drbd12: max_segment_size ( = BIO size ) = 32768
block drbd12: drbd_bm_resize called with capacity == 146796088
block drbd12: resync bitmap: bits=18349511 words=286712
block drbd12: size = 70 GB (73398044 KB)
block drbd12: recounting of set bits took additional 0 jiffies
block drbd12: 0 KB (0 bits) marked out-of-sync by on disk bit-map.
block drbd12: disk( Attaching -> Outdated )
block drbd12: Barriers not supported on meta data device - disabling
block drbd12: conn( StandAlone -> Unconnected )
block drbd12: Starting receiver thread (from drbd12_worker [4304])
block drbd12: receiver (re)started
block drbd12: conn( Unconnected -> WFConnection )
block drbd12: Handshake successful: Agreed network protocol version 90
block drbd12: conn( WFConnection -> WFReportParams )
block drbd12: Starting asender thread (from drbd12_receiver [4667])
block drbd12: data-integrity-alg: <not-used>
block drbd12: drbd_sync_handshake:
block drbd12: self
bits:0 flags:0
block drbd12: peer
bits:4842 flags:0
block drbd12: uuid_compare()=-1001 by rule 30
block drbd12: To resolve this both sides have to support at least protocol
block drbd12: conn( WFReportParams -> Disconnecting )
block drbd12: error receiving ReportState, l: 4!
block drbd12: asender terminated
block drbd12: Terminating asender thread
block drbd12: Connection closed
block drbd12: conn( Disconnecting -> StandAlone )
block drbd12: receiver terminated
block drbd12: Terminating receiver thread

It looks like it's handshaking and agreeing on a common protocol fine,
but then disconnects with a message to the contrary.  Has anyone run
into a similar situation?


More information about the drbd-user mailing list