On 06/07/2014 21:25, Bzzzz wrote:
On Sun, 06 Jul 2014 20:54:10 +0100 Ron Leach<ronleach@tesco.net> wrote: Oops, I read a tiny bit too fast.machine to Wheezy. So I need to partition the new disk, and I'd like it to be an exact clone of the existing RAID1 member, so that each partition starts on the same sector, etc. I can then repair the arrays using mdadm.You can still use dd to copy the partition table (others will tell you the right syntax); however, RAID easily copes with bigger partitions, as it only uses the place it needs.
Bzzzz, thank you.dd leads to problems with RAID, though. I did try that first, and messed the system up further. I hadn't included that story in the original post, because I hadn't wanted to write something too long; but here it is.
Debian Lenny uses Lilo to boot from a RAID1 and when you do a dd over sda -> sdb you do, indeed, get a bit for bit copy. But, you also get an exact replica of the disk ID, and Lilo complains about that (but does go on to boot).
More seriously, mdadm seems to have a kind of 'dynamic' or 'live' repair/re-assembly capability. While I was dd-ing, mdadm tried to also do a re sync on each partition as it came into existence. (I was surprised by this.) The result was two programs writing to the same areas and mdadm evenually entered a somewhat strange state, and stated renaming the /dev/md[n] to something else - I now have a /dev/md126, even though mdadm.conf still has /dev/md2. But I've left it because the system does boot up, for now. So, the RAID1 isn't perfect yet, and won't be after the 2nd disc is added, but I see on the linux-raid list that someone else has reported this issue of md renaming so I hope to fix that, as well, afterwards.
So I do just want to clone the GPT partition table, if I can, and let mdadm re sync the data in the partitions. DD does seem attractive, I agree, but leads to problems in this instance.
Bzzzz, many thanks for thinking about this, regards, Ron