Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Am 01.04.2011 um 09:54 schrieb Helmut Wollmersdorfer: > > Am 31.03.2011 um 18:02 schrieb Brian R. Hellman: > >> If you're really sure you want to be primary and blow away the data >> on >> the other node you can do: > >> drbdadm -- --overwrite-data-of-peer primary drbd1_2 > >> Where drbd1_2 is the device you want to promote to become your new >> primary. > > root at xen09:/# cat /proc/drbd > version: 8.3.7 (api:88/proto:86-91) > srcversion: EE47D8BF18AC166BE219757 > > 1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/Outdated C r---- > ns:0 nr:0 dw:0 dr:200 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos: > 1424 > 2: cs:WFConnection ro:Secondary/Unknown ds:Consistent/DUnknown C r---- > ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0 > > root at xen09:/# drbdadm -- --overwrite-data-of-peer primary drbd1_2 > 2: State change failed: (-2) Refusing to be Primary without at least > one UpToDate disk > Command 'drbdsetup 2 primary --overwrite-data-of-peer' terminated > with exit code 17 > > If there is no way to reuse the device then it's a grave bug or > misconception of DRBD. > Isn't it the main reason to use DRBD to have a usable device in the > case of a damaged hardware-node? Now changed the topic to 'critical' bug, because it's a show-stopper for my project. Read TFM again and again -- no solution. Helmut Wollmersdorfer