Pat Regan wrote: > Kevin Otte wrote: > >>- Mirror partition sizes >>- Change LVM (0x8e) to RAID (0xfd) on the new HD > > How did you mirror the partition sizes?
By hand with fdisk. > If I were doing this booted from a rescue cd like you are I would have > created a new volume group and copied the data. It would likely be faster. I have 7 LVs with varying FS types. I was trying to save myself the trouble of moving them each by hand. > pvmove and vgreduce are going to be slow because they are meant to be > used on a running filesystem with no loss of service. I tried this once on a running machine and lost control of it. Perhaps this was a fluke. > I would have hoped that the pvremove and initialization of the array > would have removed the duplicate lvm superblock. The only thing I can > think of is that it might have caused trouble if you used dd to copy the > partition table. I don't know the exact details of where md and lvm > store their metadata, but it sounds like it may be possible for them to > coexist well enough on the same block device to confuse themselves. The way I see it, the RAID information is stored in a "superblock" outside the partition, and the LVM PV information is stored in the first few sectors of the partition. Thus when pvscan ran across all the partitions, it saw the same UUID in two different partitions. This is also why I was able to fail back to using the single disk after the fiasco. > I don't think that it is stupid that it scans all partitions. I am just > terribly surprised that it can find an lvm signature on a block device > that is part of an md device. I would have thought that the md > signature would get in the way. Like I said though, I have no idea how > those signatures are stored (I only know they are there :p). It turns out there is a setting in /etc/lvm/lvm.conf to control whether or not LVM ignores partitions with an MD superblock. The default is to ignore them (which seems sane to me), but Debian for some reason as told it NOT to ignore them. -- Kevin -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
