Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 2/28/12 6:58 PM, Lars Ellenberg wrote: > On Wed, Feb 29, 2012 at 12:54:34AM +0100, Lars Ellenberg wrote: >> On Tue, Feb 28, 2012 at 06:32:28PM -0500, William Seligman wrote: >>> Is there any way of downgrading 8.4.1 to 8.3.12 without erasing the drbd >>> partition? When I try to start drbd 8.3.12 on a 8.4.1 partition, I get: >>> >>> >>> # service drbd start >>> Starting DRBD resources: [ >>> admin >>> no suitable meta data found :( >>> Command '/sbin/drbdmeta 0 v08 /dev/md2 internal check-resize' terminated with >>> exit code 255 >>> drbdadm check-resize admin: exited with code 255 >>> d(admin) 0: Failure: (119) No valid meta-data signature found. >>> >>> ==> Use 'drbdadm create-md res' to initialize meta-data area. <== >>> >>> >>> [admin] cmd /sbin/drbdsetup 0 disk /dev/md2 /dev/md2 internal --set-defaults >>> --create-device --fencing=resource-and-stonith failed - continuing! >>> >>> s(admin) n(admin) ]. >>> >> >> You should have done "drbdadm down all; drbdadm apply-al all" while still on 8.4. >> That should have taken care of cleaning up the meta data. >> There are some corner cases where this did not work, however. >> I think we have fixed them all, meanwhile. 8.4.2 is comming "soon"... It's much less painful for me to re-upgrade to 8.4.1, type those commands, then re-downgrade to 8.3.12. So that's what I'll do. >>> OK, but when I try the suggested command: >>> >>> # drbdadm create-md admin >>> pvs stderr: /dev/md2: Skipping (regex) >>> pvs stderr: Failed to read physical volume "/dev/md2" >>> pvs stderr: Unlocking /var/lock/lvm/P_global >>> pvs stderr: _undo_flock /var/lock/lvm/P_global >>> >>> md_offset 2873200996352 >>> al_offset 2873200963584 >>> bm_offset 2873113276416 >>> >>> Found LVM2 physical volume signature >>> 2805774684 kB left usable by current configuration >>> Could not determine the size of the actually used data area. >>> >>> Device size would be truncated, which >>> would corrupt data and result in >>> 'access beyond end of device' errors. >>> If you want me to do this, you need to zero out the first part >>> of the device (destroy the content). >>> You should be very sure that you mean it. >>> Operation refused. >>> >>> Command 'drbdmeta 0 v08 /dev/md2 internal create-md' terminated with exit code 40 >>> drbdadm create-md admin: exited with code 40 >> >> drbdmeta create-md detects the LVM meta data signature, >> and calls out to pvs to do the meta data parsing. >> Your filter in lvm.conf correctly tells pvs to ignore the lower level >> device, so drbdmeta can not determine the size, and plays it safe. >> >> If you invoke it like so: >> LVM_SYSTEM_DIR= drbdadm create-md vm1 > > Of course > LVM_SYSTEM_DIR= drbdadm create-md admin > > Obviously that's copy/paste nonsense from a previous mail ;-) Thanks for the correction! >> pvs will not find your lvm.conf, >> default to it's builtin filter settings, >> which should allow it to read and parse the LVM meta data block. >> drbdmeta should then figure that the currently used space is much less >> than the device size, and that it is ok to create the meta data. >> >>> Since I'm not certain that the problems I'm having with cman+pacemaker+drbd are >>> caused by my drbd version, I'm reluctant to do this (and spend several hours >>> restoring the partitions) unless I absolutely have to. >> >> You could also give us call ;-) I have brought this up more than once with my superiors; the cost in time I've spent re-inventing (and de-inventing) the wheel far exceeds the cost of purchasing LINBIT support. Let's hope I can make a good case. -- Bill Seligman | Phone: (914) 591-2823 Nevis Labs, Columbia Univ | mailto://seligman@nevis.columbia.edu PO Box 137 | Irvington NY 10533 USA | http://www.nevis.columbia.edu/~seligman/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4497 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120228/4c882c01/attachment.bin>