OEM hard disk replication SOLVED?

[Chadley Wilson]

> On Wed, 2010-03-03 at 09:36 +0200, Chadley Wilson wrote:
> [snip]
> > So for all you fellows out there trying to duplicate hard drives,
> >
> > Edit /etc/fstab
> >
> > There are 4 lines
> >
> > # / was on /dev/sdaX during installation
> > UUID=xxxxxxxxxxxxxxxxxxxxxxxxx  /       ext3    errors=remount-ro
> > 0        1
> >
> > And
> >
> > # swap was on /dev/sdaX during installation
> > UUID=xxxxxxxxxxxxxxxxxxxxxxxxx  none    swap    sw
> > 0       0
> >
> > Replace the UUID=xxxxxxxxxxxxxxxxxxxxx with the relevant /dev/sdaX
> >
> > Then you need to regenerate your  grub
> [snip]
>
> I just wanted to confirm... judging by this solution, I assume that for your
> situation, the partition UUIDs were in fact changing when you duplicated the
> disks?
>
> If this is the case, it makes me a sad panda (or...confused, which may be
> more appropriate here)... as I was under the impression, as someone else
> pointed out, that duplicating the disk should preserve the partition UUID...
> therefore making this a non-issue...
>
> So, I suppose my question is this: How is the duplicator actually duplicating
> the hard drives? Is it a bit-for-bit copy process? a straight partition copy?
> something like a RAID mirroring process? I do know that at the very least, the
> latter-most option does duplicate UUIDs (at least in my experience) since the
> drives are treated as the same device...allowing you to boot from either
> copy...
>
> I ask this question mainly for posterity, but also out of sheer curiosity. Maybe
> you could provide a link to your duplicator's spec sheet so I could research it
> myself? (or if you don't want to for trade-secret reasons or whatever, a
> duplicator similar to it?) thanks!
>
[>] Nope!  the problem is that the UUID is NOT changing and that is causing the problem.

Duplicating the hard drive is preserving the UUID's. Because they are written into the grub.cfg and the efstab

By enabling this setting  and rebuild the grub config -
GRUB_DISABLE_LINUX_UUID=true

The system reverts back to /dev/sdaX dropping the UUID system altogether.
But you still need to edit out the UUIDs from the fstab as I discovered this morning...

Now I am not entirely sure how it works. But it seems that grub has a lot to do with it.
If I take the drive and plug it into a completely different spec machine, it boots and redetects all the hardware. No prob... that works as it was pointed out in one of the posts. But it is the same physical hard drive which I plug into both machines.

Now because it is the same HARD DRIVE :) the UUID will always be the same hence why the hard drive can boot in any system.
But when you duplicate the drive even block by block. The new or destination drives will each have their own unique UUID. But the image which is duplicated on those destination drives will contain the UUID of the master.
 Hence why the system fails to boot.

So to work around it you need to revert back the old school way of declaring the device in the two config files.





Pinnacle Technology Holdings E-Mail Disclaimer:

This e-mail is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Pinnacle Technology Holdings any of it's divisions or affiliates. If you are not the intended recipient, be advised that you have this e-mail in error and that any use, dissemination, forwarding, printing, or copying of it is strictly prohibited.