pvcreate to raid1 fails

[Benjamin Scott]

On Wed, Mar 3, 2010 at 9:23 AM, Jerry Feldman <gaf at blu.org> wrote:
> I am running Fedora 12 with kernel 2.6.31.12-174.2.3.fc12.x86_64
> LVM is lvm2-2.02.53-2.fc12.x86_64

  Does Fedora have an updates for the kernel or LVM (or device mapper,
etc.) to install?

> I've posted the details at: http://pastebin.com/4AtMzEjr

  Your two disks (eventually to be mirrored) are identical in size,
but the partition tables are different.  That is okay, but it may
confuse people and/or software.  For example:

  md1 (currently only on sdc2) is bigger than sda2.  You will not be
able to mirror md1 back on to sda2 without repartitioning sda, which
will mean removing sda1 from md0.

  According to the output of "fdisk -l", the end of sda1 and the start
of sda2 both occur within cylinder 26.  This may or may not be a
problem.  Can you post "fdisk -lu /dev/sda" output so we can see exact
sector layout?  I want to make sure the partitions do not overlap.

  According to IBM/Microsoft, partitions start and end on cylinder
boundaries.  If you ever use any OS or software which assumes
IBM/Microsoft semantics, that may cause data loss, since as far as
such software sees things, your partitions overlap.  And IBM/Microsoft
did define the pee sea partition table format...

  The cylinder boundary issue isn't supposed to matter to Linux (as
long as sectors don't overlap), but partitioning in the pea sea is
such a crock that it still has me worried.

  You may also want to compare the output of "fdisk" with the output
of some other partitioning programs, just to see what other code
thinks of your partition table.  Sometimes different implementations
will disagree.  (See above about crock.)  Try "sfdisk -l".  You can
modify that with "-uS" to report sectors, "-uB" for blocks, or "-uC"
for cylinders.  Also try "parted"; the "print" command, optionally
after various "units" commands.

  Other than that, things look okay.  The kernel sees your partitions
as they are defined on disk, RAID is reporting sensible information,
LVM doesn't appear to think sdc2 is already in a VG or anything dumb
like that.

On Wed, Mar 3, 2010 at 10:21 AM, Jerry Feldman <gaf at blu.org> wrote:
>> $ grep -lr "must not be less than" LVM2.2.02.61
>
> The message comes from LVM2.2.02.61/lib/format_text/format-text.c

  Neat.  Whoever wrote that code split the error message across
multiple adjacent C literal strings.  Sometimes I wonder if
programmers are deliberately making our lives harder.

  BTW, good catch.  How'd you find that?  :)

> I would suspect that possibly pe_align_offset may either not be
> initialized properly ...

  Is the incredibly-large-number different for different runs of the
program?  (If so, it's prolly an uninitialized variable; if not, it's
prolly broken program logic doing something consistently non-sensible.
 Not that that helps us much.)

  I note that you're running x86-64.  I wonder if it's programmer
brain damage, assuming that all integers are 32 bits wide.

> ... or is picking up incorrect information since
> /dev/sdc2 starts at cylinder 26.

  That *should* be okay, because sdc1 ends on cylinder 25..

-- Ben